STM32F769i-Disco -Moving working memory to SDRAM, HAL_GetTick() returns 0

[SLimi.1]

I am creating a project that will run Azure RTOS and GUIX App. Due to the size of GUIX, the SRAM is not large enough to run the application. I was looking to use STM32H747i-Disco which has enough RAM, but it was a little too complex and the support drivers are a mess. The STM32F769i-Disco is a simpler board to work with, which I have been able to get working. I am working from the ground up and testing some basic concepts before adding Azure RTOS to the mix.

The first step was to get the LCD work. Following the project here: https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F769I-Discovery/Examples/LCD_DSI/LCD_DSI_CmdMode_DoubleBuffer I was able to adapt the project to get the LCD work. The sample messages, drawings, and picture appear on the LCD screen.

The next step is to move from SRAM to SDRAM. Adapting this project: https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F769I_EVAL/Examples/FMC/FMC_SDRAM_MemRemap. The recommendation is to have the SDRAM remapped to 0x60000000 so it is not XN section per PM0253. I put the frame buffer to 0x60400000 so it is away from working RAM. . I am using TIM6 for a Time base sources for when Azure RTOS will be added to the project. Note: If I leave the timebase to systick, the application crashes on the call to   HAL_Init();

I have been able to get the system up and running to a point.

When the call is made to MX_DSIHOST_DSI_Init(), way down in the HAL code is a call to HAL_GetTick(). The value return is always 0 (uwTick), thus the code gets stuck in an infinite loop and never returns from the function call.  It appears uwTick is not getting updated.

If I leave everything in SRAM and step through the code, HAL_GetTick() returns an expected value (uwTick) and everything is working fine. The move to SDRAM kills something, somewhere.

What am I missing? Where do I need to look to diagnose why uwTick is not getting updated? I have not found much information about this topic other than the example and this post :https://community.st.com/t5/stm32-mcus-products/how-to-run-a-program-in-sdram-on-stm32h743/m-p/262615

Any insights would be helpful.

[SLimi.1]

Here is the project.

[waclawek.jan]

Is SDRAM working at all? 

JW

[SLimi.1]

@waclawek.jan 

It appears to be. As a test, an integer variable is created and incremented in the code. In the memory view, I can see the integer value changing on the remapped SDRAM starting at 0x6000 0000. It is the timer tick that doesn't work. Is there something that has to be remapped for the timer interrupts?

[SLimi.1]

@waclawek.jan 

After further investigation, it appears the global variables are not set in the SDRAM. HAL_GetTick simply returns an increment of  uwTick += uwTickFreq;. uwTickFreq is supposed to be the value 1, but in memory it is 0. I ran into another variable that was supposed to be set to a value, but it wasn't. 

The issue appears to be the globals are not being populated in to SDRAM.

[SLimi.1]

@waclawek.jan @Bornason 

It looks like someone tried to do the same thing a couple years ago: Solved: How to run a program in sdram on STM32H743 ? - STMicroelectronics Community

I am not sure what the solution is. The Linker script matches the GitHub example. The .data and .bss sections are mapped to SDRAM. Not sure why the constants and globals are not getting into SDRAM.

[Piranha]

You have to modify the initialization code in the startup*.s file and/or modify the linker script file.

[SLimi.1]

@Piranha I modified both by following the example here: STM32CubeF7/Projects/STM32F769I_EVAL/Examples/FMC/FMC_SDRAM_MemRemap at master · STMicroelectronics/STM32CubeF7 · GitHub

Playing with the linker script file, I changed the example's configuration of .data segment of >SDRAM AT> FLASH back to >RAM AT> FLASH the predefined global variables are set, and the app is able to run through the code and see something on the screen. Eventually, a Memory Management fault gets triggered. A little more progress, but very puzzle how RAM could be split up like this. Why does >SDRAM AT> FLASH not work. 

 

 

 

[SLimi.1]

@Piranha and @waclawek.jan 

The problem boils down to SDRAM .data section pointing to the globals in Flash. I cannot be the only one wanting to move RAM from SRAM to SDRAM. Is there a register that needs to set for the mapping between SDRAM and Flash can be performed?