SystemInit_ExtMemCtl(), DATA_IN_ExtSDRAM and SDRAM support

[tdjastrzebski]

Looking for the right way of using external SDRAM memory on my DISCO_F769NI board I found this official document on STM32F7 Series system architecture and performance - AN4667 Application note.
According to this document:

DATA_IN_ExtSDRAM: if defined in the configuration project, the SDRAM is configured to be used either for data storage or for code execution.

But I figured that mbed-os 5 does not support DATA_IN_ExtSDRAM macro, at least not for DISCO_F769NI target.
What is more, it seems that the new way is to define own HAL_SDRAM_MspInit() methof or some MspInitCallback() which gets called from HAL_SDRAM_Init().
However, unlike SystemInit_ExtMemCtl() HAL_SDRAM_Init() is not executed upon system start from SystemInit().
Also, I found SystemInit_ExtMemCtl() is mentioned in startup_stm32f769xx.s file - some publications say that it should be invoked from there but I am not sure it really is.

I am not asking just how to make SDRAM working - there are some examples available.
I am asking how to do it the right, mbed-os 5/6 way so I can submit PR and make sure next release will not overwrite necessary OS changes - if any are required.

Also, probably LTDC buffer and DMA, should be set up at the same, early stage. What is the recommended pattern?

Could some architect point me to the right direction, please?

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2621

[jeromecoutant]

Hi

To be honest, I don't know a lot about SDRAM feature...
Maybe you can start with this example:
https://os.mbed.com/teams/ST/code/DISCO-F769NI_SDRAM_demo/

@kjbracey-arm

Regards,

[tdjastrzebski]

@jeromecoutant This is a nice demo but I am afraid it is not a 'production grade' solution.
To be safely used for heap, stack and LTDC buffer, SDRAM should be initialized before control is passed to main().

This demo uses stm32f769i_discovery_lcd and stm32f769i_discovery_sdram files no longer included with mbed-os 5. Probably those files were excluded for a reason.

Like I said, there are demos available, but I am asking what is the correct mbed-os 5/6 pattern.
A pattern which would allow the OS to set SDRAM for heap, stack and LTDC buffer. It is a typical requirement of any larger production applications using MIPI-DSI display.

[0xc0170]

https://os.mbed.com/docs/mbed-os/latest/reference/bootstrap.html - for bootstrap. This should clarify where you can execute functionality prior main.

There is an example for gcc to set up heap: https://github.com/sabmeua/heap_ext_DISCO_F746NG. as sbrk is weak, you can overwrite it like this.

To set stack, you should modify your linker script.

[tdjastrzebski]

@0xc0170 Thank you for the example.
My question is of architectural nature. What is the correct mbed-os 5 usage pattern?
Should SystemInit_ExtMemCtl() function and DATA_IN_ExtSDRAM macro be used?
If so, how exactly they should be used?
How about HAL_SDRAM_MspInit()?

[tdjastrzebski]

@0xc0170 One comment. I assumed mbed-os has ambitions to address proper memory initialization, including heap/stack in SDRAM as well as LTDC buffer. Some code I found in current version suggest that.
However, maybe this is an area planned to be addressed in future (7+?) releases. To be honest, I have not seen any road map.

[0xc0170]

The functions are target specific, so in this case someone from @ARMmbed/team-st-mcd could know more.

My question is of architectural nature. What is the correct mbed-os 5 usage pattern?

There is no generic support for this currently. You have to set it up manually as it's target specific (what is there is to use hooks in the bootstrap). What would you like to have there, provide more details.

@0xc0170 One comment. I assumed mbed-os has ambitions to address proper memory initialization, including heap/stack in SDRAM as well as LTDC buffer. Some code I found in current version suggest that.

Give an example how would you imagine have this working - external memory initialization with available hooks Mbed OS provides. What is missing ? What code have you found, can you share?

[kjbracey]

A bit more info: Mbed OS does not have any current generic notion of different classes of memory. All memory layout decisions are fundamentally down to the target, and to some extent the toolchain (each target has one linker map per toolchain).

It would be the target initialisation code's responsibility to initialise the SDRAM. The files in the higher directory levels of each TARGET_xxx for STM are generally the Mbed OS glue where that should happen.

SystemInit is in system_clock.c for Mbed OS targets, and it seems like that's where SDRAM init should happen, as the next step is static memory initialisation which will need it ready. A target with SDRAM would definitely be a distinct Mbed OS target, as it would have a clearly distinct memory map. It could either be implemented by cloning an existing board to make a new board, or you could add a bunch of #ifdefs into the code, including the map files.

If STM documentation suggests having a separate SystemInit_ExtMemCtrl, that would work too, but as you note you would need to update the relevant startup.s files.

As long as some form of system init gets the RAM ready, then you should be free to reorganise the linker maps to put whatever you want there rather than in SRAM. If the linker map says the static data and/or heap and/or main stack go there, then they will go there. Initialisation is automatic - you just need to specify the addresses in the linker map.

Different toolchains have different capabilities about how to direct stuff to multiple regions, which can be annoying. But the simplest case of "put basically everything in SDRAM except maybe a few named items in SRAM" should be doable. SDRAM doesn't offer any new challenges there - we already have devices with multiple SRAM regions you can copy patterns from.

[tdjastrzebski]

@0xc0170 DATA_IN_ExtSDRAM mentioned in AN4667 can be found in:

system_clock.c

#if defined (DATA_IN_ExtSRAM) || defined (DATA_IN_ExtSDRAM)
    SystemInit_ExtMemCtl();
#endif /* DATA_IN_ExtSRAM || DATA_IN_ExtSDRAM */

startup_stm32f769xx.S

/* stack used for SystemInit_ExtMemCtl; always internal RAM used */

I do not know how this should work. That is why I ask hoping there was some mbed-os architect who could share his/her vision.

[kjbracey]

Okay, it looks like at least a subset of targets do have this functionality present. So the simplest pattern to me would seem to be

• Define a new target in targets.json inheriting from some base target.
• That target defines DATA_IN_ExtSDRAM, but is otherwise the same. Maybe it has or sets some target options for SDRAM size/config.
• Share the target code with the base target, so just ifdefs separate the behaviour
• An ifdef makes SystemInit call SystemInit_ExtMemCtl() to get it ready. That would call HAL_SDRAM_Init.
• The linker maps will have a great big ifdef with an alternative layout, putting heap, static data in the SDRAM.

The boot/interrupt stack should remain in SRAM. It has to be there for bootstrap, and it makes sense to keep it there for interrupt response speed. The other stacks can live in SDRAM (thread stacks for the RTOS, and the stack used for "main".)

[adbridge]

@tdjastrzebski please note in the future these type of questions should be raised on our forums rather than here. GitHub is for actual defects only. Thanks.