cancel
Showing results for 
Search instead for 
Did you mean: 

Changing from 16bit to 32bit SDRAM Problem

DSand.5
Associate III

0693W00000JPXoKQAX.pngI am working on a project what started with a ST32F7508-DK, and I generated the code and project in TouchGFX. Everything was working fine. Then we decided to go from 16bit SDRAM to 32bit SDRAM. So we created a board that was a copy on the discovery kit, the only difference was that we added the pins needed for migrating to the 32 bit, which resulted in needing to move some of the pinouts for the ltdc (screen). Now after that change, I am having issues flashing and running identical programs on the board (identical meaning the main code and touchgfx code did not change). When trying to flash in STM32Programmer, I am getting the message:  

18:55:58 : Error: Data mismatch found at address 0x90000002 (byte = 0x00 instead of 0x05)

18:55:58 : Error: Download verification failed

Also, when looking at the memory visualizer, it seems like nothing is flashing to anythgin past 0x90000000. I was wondering if I messed up something in the SDRAM configuration, am i missing something in the bootloader/linker file, etc. This issue is also repeatable with the same hex file on a different machine and a different board.

I am also somewhat new to this, so any help would be great. Thanks.

13 REPLIES 13

Did you change the QSPI pins or​ NOR Flash memory?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Yes. The memory changed, and the additional pins were added. I changed this in the ioc. Is that what you meant?

I mean did you change the design vs that of the STM32F7508-DK wrt the QSPI, because if you did the External Loader isn't going to work. It is tied to a board design, has a name reflecting that, and doesn't magically change with CubeMX settings.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Ahh I see. According to the schematic, the pins are the same (into the mcu), but it is a different model chip for the QSPI, and a different model chip for the SDRAM. If that is the issue, what would I have to change to make it work?

The error from STM32 Cube Programmer indicates the QSPI memory space in the 0x90000000 region wasn't written properly, and is arguably unrelated to what you've done regarding the SDRAM.

You'd need to write a loader for your unspecified NOR memory, and select that in your IDE so the download process uses that instead.

Would suggest getting your BSP implementation for the QSPI memory working first to validate that and your board design.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

thanks a bunch =). However, I have never done that before. Are there any guides you can send my way in order to do this? At least in a way that I can get started. Once again, I have never had to do anything like that before.

ST has some videos on External Loaders, I'm not sure how helpful they are. ST has some example code in the branches of the STM32 Cube Programmer and ST-LINK Utilities installations, as well as some GitHub examples, the latter don't seem to be coded by the same people, or using the same methods, as many of the .STLDR files provided for the DISCO/EVAL boards.

The BSP components for the DISCO/DK board are probably a good starting point to see working code for a QSPI implementation. You'll need to pull the data sheets for your unspecified device and digest that in the context of the read, write, erase and initialization contexts.

Repository\STM32Cube_FW_F7_V1.16.2\Drivers\BSP\STM32F7508-Discovery\stm32f7508_discovery_qspi.c

I've published some pre-built External Loaders that I've fashioned.here, covering as many popular pin combinations as I've encountered

https://github.com/cturvey/stm32extldr

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
MM..1
Chief II

If pinout for new QSPI is compatible with original DK replace QSPI chip

Ok, so it turns out that although the QSIP chip has changed, we never implemented it. We were planning on using it once the project got larger, but for now we are only using the SDRAM and the normal MCU flash memory. Also, it seems that after some clarification, the SDRAM also has not changed. The only difference is that before we wired it up for 16 bits (just like the discovery kit), and now we wired it up for the full 32bit.

So I guess the question would be, if I took a discovery kit, and kept everything the same except for wiring it up for 32bit as opposed to 16 bit, what would I have to change?