cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743II FMC + 8080 LCD spurious writes

Piotr S
Associate II
Posted on April 20, 2018 at 11:55

Hello,

I'm interfacingSTM32H743II with 8080 parallel bus LCD. I configured FMC in CubeMX as LCD Interface with 16bit bus and A11 as R/S pin. However I've run into problem with writing commands/data into LCD. A single uint16_t write under 0x68000000 address results in 4 writes to memory, out of which first write is valid data, and rest are 0, as seen on logic analyser snapshot.

0690X0000060AhJQAU.png

Write is performed by following code:

#define COMMAND_POINTER 0x68000000
#define DATA_POINTER 0x68001000
...
static uint16_t * command = (uint16_t *) COMMAND_POINTER;
static uint16_t * data = (uint16_t *) DATA_POINTER;
...
*command = ILI9341_SWRESET; //software reset�?�?�?�?�?�?�?�?�?�?�?

I also tried HAL_SRAM_Write_16b(), but result is the same.

These writes basically compile to strh (Store register halfword) instruction, and executing this single instruction causes 4 write accesses to LCD. After little investigation i noticed, that writes under incremented address, for example 0x68000002 causes valid data only in second write operation, write under 0x68000004 causes valid data only in third write and so on. It's like FMC tries to write whole 64bit memory block at once.

ICache and DCache are disabled, i tried to disable FMC write FIFO, but it doesn't change much. Needless to say this FMC behaviour throws off communication with LCD.

Am I not taking some detail into account? i would like to avoid bitbanging LCD signals or changing HW design.

#stm32h7 #lcd #h7 #fmc
18 REPLIES 18

From what I understand, all the writes are correct. The CPU is assuming that the device, to which its writing, has address lines A2..A1.

These four 16-bit writes, of which only the first contains the "correct" data, represent the writing of one 64-bit cacheline to RAM.

If this had been addressable memory, the address lines A2..A1 would have gone through the values 00, 01, 10, and 11, writing to 4 separate 16-bit words.

(I don't know whether those address lines are, or can be, brought out to pins, but they are not on the logic analyser output.)

It's not unreasonable that the CPU must be told that this particular address range does not contain normally-addressable memory, but instead contains 16-bit IO registers with semantics which differ from those of memory.

I beg to disagree.

Even in "normal" memory, if the processor writes only 16 bits (i.e. 2 bytes or one halfword), and the memory system actually writes 8 bytes, it means, the RAM content is corrupted.

JW

You may well be right, I'm not an expert on the STM32.

My guess at what is going on (for RAM, not IO) is that CPU believes that the cacheline already has the correct and current contents of the higher three halfwords.

So when it writes to RAM in this manner, there is no corruption. Multiple writes of the same values to the same addresses have no effect on RAM, but they do have an effect on IO. Hence the behaviour changes when you tell the CPU that the region is not RAM.

I expect that you wouldn't see this behaviour on an STM32 without a data cache (or with it turned off).

If I were interfacing a 1Mbit x16 SRAM via the FSMC/FMC, this 4-halfword write pattern would not be a problem, and the use of the CPU data cache for my SRAM would help its performance.

Well, I don't know what was your particular setup, but the opening post says:

> ICache and DCache are disabled

I could understand the AXI logic still attempting to write 64 bits for Normal area (memory), provided that it first *reads* the whole 64 bits, too, before the wirite.

I don't have an 'F7/H7 at hand; if anybody could try this, I'd like to hear the results.

JW

Hello,

Thanks for your code.

Are you sure of the value 19 (which corresponds to a region of 1MB)? Isn't it 0x19 rather which corresponds to a region of 64MB?

cf stm32h7xx_hal.c :

#define  MPU_REGION_SIZE_64MB   ((uint8_t)0x19)

Jean-Louis

You saved the day... I had the exact same issue. even more I tried the whole morning to use MPU, but I still got issues when running in privileged mode as if it was using the background region... then I started to look in forums...

Using setFMCMemorySwappingConfig resulted in an Hardfault for me after changing the addresses to 0xC...0.

I solved the problem not using the memoru swap but by using MPUConfig and set the ox6...0 area as non_cacheable, other settings were bufferable,shareable with size 64MB​. Now FMC gives me around 20fps on a 800x480 tft with ssd1963.

I wonder why using memory swap results in hardfault, anyone got ideas?

Mcu:F746ZG​

​____

​MVR

no, but I suggest to check HFSR and if bit 30 is set check CFSR. if you have MPU enabled it might be exactly that.

I realize this is ancient history, but I'm having the same issue with hard faults - which I believe is because A0 as the RS line for the LCD so that makes the cmd address 0x60000000 and data address 0x60000002 which is not 32 bit aligned.  Did you figure out a way around this?