ILI9320 driver error

[Ceco]

Hello.

I have made some experiments with ILI9320 driver included in trunk. Maybe there is an error in file gdisp_lld_board_olimex_stm32_lcd.h
As I understand this file is prepared for this board: https://www.olimex.com/Products/ARM/ST/ ... ematic.pdf
The CS signal of TFT display is connected to NCE2-NE1-PD7.

But in the code we have the following:

Code: Select all

static __inline void GDISP_LLD(init_board)(void) {
......

    /* const unsigned char FSMC_Bank = 0; */
    const unsigned char FSMC_Bank = 6;
......
}

I think the commented line /* const unsigned char FSMC_Bank = 0; */ is correct.
But const unsigned char FSMC_Bank = 6; is compiled instead, which is wrong. With this code we address FSMC registers which are not related to address space of NE1.

[Tectu]

Hello Ceco,

Thank you very much for your feedback.
I current don't have the hardware arround but I will try it out tonight!
But anyways, I am 95% sure that this worked for me... Don't you get any output with «the wrong code»?


Kind regards,

~ Joel Bodenmann

[Tectu]

Hello Ceco,

As promised, I just took a look at this problem. I tried both way out (one with 0, the other one with 6). I can compile and run both of them correctly.
Do you have issues? Dosen't your board work with the 6 instead of 0? But anyways, I somehow agree with you that 0 is the correct value here.


~ Tectu

[Ceco]

I have a custom board which is similar to Olimex one (STM32_LCD). Similar means - it uses the same TFT routing to microcontroller.

In fact, If i use "6" instead "0" there are no compilation errors. The problem is that a wrong FSMC register is accessed.

The FSMC system of STM32 is a bit complicate. Bank1 is used for SRAM (TFT in our case). But Bank 1 has 4 sub-banks (64MB each) with 4 independent CS pins - NE1 to NE4. The actual code will access the registers corresponding to NE4. But physically NE1 is connected to TFT. So the code will compile without errors but it not works.

Actually I'm working on ILI9328 driver. I have some TFT's from ebay with this controller. It seems similar to ILI9320, there are minor changes in initial configuration. When I have a working driver, I will share it with you.

[Badger]

I don't think FSMC bank should be 6 - there are only 4 BTR registers. Probably the only reason it still works with bank = 6 is because the default FSMC settings work and you end up overwriting the wrong register.

[Ceco]

Like I wrote before, FSMC system of STM32 is a bit confusing for configuration. FSMC_bank = 6 doesn't mean bank 6 is addressed. Each bank has a pair of 32 bit registers (BCR & BTR) . When we access with FSMC_bank = 6 we access BCR4 register and with FSMC_bank + 1 - BTR4 register. This means that NE4 pin will toggle, instead of NE1 which we need for current STM32_LCD implementation.

It's really crazy. But this is coming from FSMC system itself... The best way will be to write a FSMC low-level driver, but it will be really difficult to abstract the registers in some clear and useful level.

[Tectu]

Can you explain me why it works with both? I really don't understand that

To the FSMC low level driver: I am really not open to restructure everything again. The driver interface has been restructed like 100 times and I've worked on many designs (sometimes only on paper&pen, some times in code), but the actual version seems to be the best one. It's a very good balance between user friendlyness and flexibility.

But anyways, if you have any good idea, which works and dosen't make stuff too messy and difficult, I am very open for it. It's also important that the different interfaces don't have complete different abstractions.


~ Tectu

[Ceco]

For me FSMC_Bank = 6 doesn't works. FSMC_Bank = 0, works fine. "doesn't work" means - compile without errors, but NE1 is not toggled when corresponding address space is accessed.

Maybe for somebody else it will works with FSMC_Bank = 6, too.....Because FSMC bank 1 is reinitialized anywhere else. Or default settings of FSMC bank 1 are good enough to work without initialization

Mainly I don't care about this in my code, because I initialize all the internal hardware in one function at the begging of program flow. I feel more safely in that way, since I see everything together in one code. So for my needs, I comment all this code related to I/Os and FSMC in the driver. The FSMC and GPIO initialization is performed in a board.c file in my case.

[Tectu]

But when we write 6 instead of 0, we overwrite the default config, right? And the code dosen't rewrite it at any port of the program...
I can make some oscilloscope action tonight.

Of course you are free to comment everything out and make it in another function


~ Tectu

[Ceco]

When we use "FSMC_Bank = 6", we access the BCTR registers for sub-bank 4. So we configure this sub-bank (delays, modes end etc.). So we have sub bank 4 configured and sub-bank 1 - not configured.
Later we address TFT via following interface:

Code: Select all

#define GDISP_REG              (*((volatile uint16_t *) 0x60000000)) /* RS = 0 */
#define GDISP_RAM              (*((volatile uint16_t *) 0x60100000)) /* RS = 1 */

These definitions are correct since the TFT is connected to NE1 (0x60000000 to 0x63FFFFFF).

But this area is in the first 64Mb of the FSMC space, so it will use the configuration for sub-bank 1. But sub-bank 1 is not configured yet, because we have configured sub-bank 4 instead of sub-bank 1.

Regardless of this sub-bank 1 is initialized after reset with some default values. Maybe there is some earlier initialization of FSMC also. So even if we don't configure sub-bank 1 here, it's possible that it works...if this default configuration matches our needs. Like any uninitialized variable ... it's not sure what happens exactly.

In my case this not works at all. So I change to FSMC_Bank = 0, so I initialize the correct sub-bank 1 and i have proper communication with TFT now.


P.S. If you want to use FSMC_Bank = 6, you need to address 0x6C000000 to 0x6FFFFFFF and you need to connect TFT to NE4