STM32H750 FMC + LCD

[SMoon.2]

I’m having some trouble related to using the FMC to interface with a LCD. 

We are using NE1 as chip select, LCD register select is A0, 16 bits of data.  When I’m scoping the signals, I’m seeing the A0 go high during 16 bit writes to 0x60000000 (command).  I only expect that to happen when trying to read/write at 0x60000002 (data).  I’ve attached a capture of this.  For the second byte, A0 is a 1, which makes sense for a normal memory address, but I was expecting A0 to be treated differently by the FMC since it is identified as the register select?

I’ve seen other code examples where the RS used is a higher bit (ex. A18), which wouldn’t have this same problem…so I’m concerned that it isn’t possible to use A0 as the RS?

This also ties into configuring the MPU correctly.  I've read up on the issues other people have had with multiple writes because of the FMC memory is configured as "normal" instead of "device" type.  But setting it as "device" type requires the addresses to be 32 bit aligned, which also doesn't work for 0x60000002.  So I might be double screwed using A0?

[SMoon.2]

I switched to using 8 bit data and it is basically working with a rough implementation...
0x60000000 command, 0x60000001 data.  A0 is now operating as I would expect it to.  Also, I'm not getting alignment issues with the addresses regardless of the MPU configuration.

Not sure what to do with this information.  Not being able to use 16 bit data will likely hurt the frame rate.

Is using A0 not allowed for 16 bit? 

[waclawek.jan]

> during 16 bit writes to 0x60000000 (command). 

How exactly did you do that?

> When I’m scoping the signals, I’m seeing the A0 go high

On the attached waveform, I see two consecutive writes, A0 being low at the first. I suspect you are writing a word, which is translated to two halfword writes by FMC.

>  I was expecting A0 to be treated differently by the FMC since it is identified as the register select?

What do you mean by"register select"? The FMC does not know you have connected a LCD, there is no dedicated mode for that (only as a marketing/Cube MX bluff), read the FMC chapter in RM.

JW

[SMoon.2]

> How exactly did you do that?

I've done both:

uint32_t *tft_cmd = (uint32_t *)0x60000000;
*tft_cmd = val;
AND
HAL_SRAM_Write_16b(&sg_hsram1, tft_cmd, &dataToSend, 1);

> On the attached waveform, I see two consecutive writes, A0 being low at the first. I suspect you are writing a word, which is translated to two halfword writes by FMC

Could be.  The confusing thing for me is that I tried 8 bit mode and it was working perfectly fine with a single write/read (using addresses 0x60000000 and 0x60000001).


> What do you mean by"register select"? The FMC does not know you have connected a LCD, there is no dedicated mode for that (only as a marketing/Cube MX bluff), read the FMC chapter in RM.

Register select for the LCD differentiates between the command register and the data register for the LCD.  This was my concern, that there is nothing special about how A0 is treated by the FMC (even though I've identified the GPIO's alternate function to the FMC), and as such you can't use A0 as a register select for a LCD in 16 bit data mode.  So the A0 is just toggling based on the underlying address.  If I want to use 16 bit mode I need to use a higher A# value so that the address line stays stable during the two writes.  But I've come across examples using A0 for LCD connections with 16 bit data, so there is conflicting information.

 

[SMoon.2]

Ok, I figured it out.  Cascade of issues.

Originally I was using HAL_SRAM_Write_16b and that requires a 32 bit aligned address (which should have been my first clue), which is why my command and data register address is a uint32_t *.  Well turns out that HAL_SRAM_Write_16b is doing 32 bit write (which is why I was seeing two writes and the A0 change).  I mistakenly thought it was two byte writes, so I didn't investigate it further.  Then when I went to use the pointer directly, it was the wrong type and still doing 32 bit writes.  

I've changed the address to be volatile uint16_t * and it appears to be working correctly now.

So basically, my bad.  Thanks @waclawek.jan for getting my brain thinking on a different path.

[garry lai]

FMC settings cannot be executed normally