STM32H747 SDRAM write problem

[RobJ]

HI,

I have a strange issue with our STM32H747 board using the IS42S16400J SDRAM chip.
We have been reading the "How to set up the FMC peripheral to interface with... - STMicroelectronics Community" page and this all seems OK.
The differences between the system described and our board is that we have 8 MB RAM instead of 32 MB and we do not use the byte lane select signals (LDQM and UDQM from the SDRAM chip are routed to ground).

When writing to SDRAM, we see (random) writes to the other 32 bits word within the same 64 bits. This is true for both 16 and 32 bits write from the CM7 core.

So writing 0x12345678 to address 0 in the SDRAM results in a random value being written to address 4. Same applies when writing to address 4 - there I see a random value appearing at address 0.

If I first write 0x12345678 to address 0 and then 0xaa55aa55 to address 0x14, I see the value 0x12345678 being writting to address 0x10.
This is almost as if the processor performs a 64 bits write with the lower or upper 32 bits getting the value that has been written to a previous location.

 

If I write multiple times within the same 64 bits, the values are OK. So if I first read (64 bits) from address 0x10 and write that same value back to 0x10, I can write to any 16 or 32 bits word within the same 64 bits.

It is almost as if the SDRAM writes are almost 64 bits with some data being cached within the CM7/cache/AXI bus/FMC. I checked to see that the SDRAM is set to non-buffered and non cachable. A similar project on the STM32H747 Discovery board works perfectly well so I must be overlooking something.
Any tips or hints on where to look would be great.

Cheers, Rob

[RobJ]

as an extra note: we confgured our project in CubeMX with the "Byte Enable" in the FMC/SDRAM configuration set to disabled.

I just verified with a clean project what the impact is of setting this to 16-bit byte enable. The only changed are the configuration of the alternate function for the GPIO pins in the HAL_FMC_MspInit() function.
It seems there is no way to configure the FMC to use the FMC_NBL0 and NBL1 lines or not.

My "virtual colleague" suggests that the STM32H7 always performs a 64 bits write to SDRAM with the NBL0/1 lines set high for the bytes that should not be written. If this is the case, then allowing to not use the PE0/1 pins as FMC_NBL lines would be an error.

Can someone confirm if not using the NBL lines (the DQM lines are tied to ground on the SDRAM chip) is OK ?

 

Rob

[RobJ]

OK,

it seems this is a "bug" in CubeMX ...

I tested this on the 747i- discovery board and as soon as I set the "byte enable" feature to disabled (and program the PE0/1 lines which would have been the NBL lines to output, low) the problem appears on the discovery board too.

We patched one of our own boards to connect the NBL lines from the processor to the SDRAM and this indeed fixed the issue.

So my conclusion is that we do need the NBL lines connected. Even though CubeMX allows us to disable this feature, it is a requirement to get the IS42S16400J SDRAM working correctly.
I still have to verify with a logic analyzer but it seems the h747 is optimizing SDRAM access by using 64 bits memory writes.

Can someone from ST please acknowledge this ?

[mƎALLEm]

Hello,

From an older reference manual revision:

I think you are in the same case as described above. So try to configure the SDRAM region as Device or Strongly-Ordered using MPU.

I don't know why the case AXI transaction size greater then memory data size with no byte selection has been removed from the specification.

Hope that helps.

[RobJ]

Thanks,

 

this seems to fix my problem.

We already had it sel to "strongly ordered" (tex = 0, bufferable = 0, cachable = 0, sharable = 0) but this did not work. Setting it to "device" (bufferable = 1) fixed the issue.

This text is indeed changed in the new reference manual. Maybe this is due to a possible configuration change in future silicon versions of the h747. It works for now but I think we will still fix this to be sure.

As a side note: I completely missed this in the reference manual. The text is exactly where I expect it to be and I even suspected that this was the case. If the reference manual would have used the same "byte enable" text as used in CubeMX instead of "byte select" I would most likely have found this.

Cheers,

Rob