Why does a FMC Memory swap for LCD on a F746 cause SPI pins to toggle when writing to 8 bit parallel LCD?

[SWood.4]

I was double checking SPI speeds and functionality and noticed SPI pins switching state when they shouldn't be. I narrowed it down and discovered this only happens when the memory swap for the FMC LCD is enabled. There are some other posts from me about getting the LCD to work. If I don't do the memory swap, this doesn't happen, so I'm pretty sure it has to do with writing to the FMC memory location.

In the image below I circled the spots where some of the SPI pins toggle during LCD writes. Zooming in on the circled spots the pins (PB5 and PA5) will change state about 3 times while writes to the LCD are happing. In the image D0-D7 are connected to the LCD data lines, channels 0-4 are connected to the SPI data lines. Why does this happen and how do I prevent it from happening? Thanks

[waclawek.jan]

My guess is inadequate ground.

JW

[Tesla DeLorean]

Sorry what's a "memory swap" in this context?

What STM32 are we talking about?

Perhaps you can capture this on a scope, the LA really doesn't confer much detail of the nature of the glitch.

Don't really know much about board/design.

If circuitous power/ground, that could be an issue with switching currents getting where you don't want.

Or is it a four layer board with power planes?

[SWood.4]

Thanks for the responses. From the RM the the memory swap is :

SWP_FMC[1:0]: FMC memory mapping swap

Set and cleared by software. These bits are used to swap the FMC SDRAM

banks and FMC NOR/PSRAM in order to enable the code execution from

SDRAM Banks without modifying the default MPU attribute

00: No FMC memory mapping swapping

SDRAM bank1 and Bank2 are mapped at 0xC000 0000 and 0xD000 0000

respectively (default mapping)

NOR/RAM is accessible @ 0x60000000 (default mapping)

01: NOR/RAM and SDRAM memory mapping swapped,

SDRAM bank1 and bank2 are mapped at 0x6000 0000 and 0x7000 0000,

respectively

NOR/PSRAM bank is mapped at 0xC000 0000

So to get the correct data to write to the LCD using FMC I need to enable the memory swap and write to address 0xC000 0000.

I have the LCD and SPI device connected to the Nucleo F746 board. I thought it may be noise on the jumpers at first. But commenting out the memory swap line (SYSCFG->MEMRMP |= SYSCFG_MEMRMP_SWP_FMC_0;) and changing the LCD write address back to 0x60000000 clears up the issue. Nothing physically changed on the connections between code changes. I enabled and disabled memory swap a few times and issue seems to follow the memory swap in the code.

I was wondering if there is another setting that that needs to change when writing to address 0xC000 0000 that I'm missing. I'm also not ruling out that the issue is coming from the jumpers to the devices, but it seems to follow memory swap in the code.

Thanks for the help.

[waclawek.jan]

> jumpers to the devices

What jumpers?

Post photo with description.

JW

[Tesla DeLorean]

Ok, I'm not aware of any external impact of changing the decode address, it should just map to the same external pins in the same way.

I'm familiar with SDRAM mapping into 0xC0000000 / 0xD0000000

For memory-mapped LCD controllers I'd be more prone to thinking they are in 0x60000000 decode region, or one of it's four 64MB subsections.

Are you sure the NUCLEO-F746 doesn't have some pin level conflicts or stub traces?

[SWood.4]

I don't spot any trace conflicts looking at the schematic and RM for the Nucleo board. I'm glad that there isn't an additional setting that needs changed. I have new proto type boards on the way so I won't need so many jumpers to bread boards. I'll see if the issue goes away when there are fewer jumpers around.

Thanks

[SWood.4]

I have wires from the nucleo header to breadboard and breadboard to LCD. That's how I verify LCD changes and speeds and make sure everything looks good using the logic analyzer. I re-routed the wires where the LA shows they are unexpectedly changing state and I see the same thing. Since there doesn't seem to be any software issues or additional settings that need changed when doing the memory swap then the issue is most likely coming from the wires and breadboard connections, it's just something I haven't isolated yet. Using the memory swap may be changing the signals on the pins/wires enough to make a bread board issue show up? Thanks for the sanity check.

[Tesla DeLorean]

I don't have any specific recollections about the NUCLEO-F746 or versions of the PCB.

A lot of the NUCLEO-144 have multiple solder bridges, creating stubs and circular connections between pins. There have certainly been builds where direct conflicts have occurred, pins on headers with no connections, multiple pins with the same connection, and changing of defaults over time.

I would generally create a checklist of pins, associated SB, and header connectivity, and go through that auditing the pins used by the interface(s) in question.

I know it's a tedious process, but it can save a lot of time, and raises awareness in one's own designs. Especially with tradeoffs about what peripherals can and can't be escaped together.