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.

[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?

[waclawek.jan]

> jumpers to the devices

What jumpers?

Post photo with description.

JW

[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.