Memory Information for stm32l452ccux is wrong in Keil.STM32L4xx_DFP.2.5.0.pack

[TNaum]

In Keil.STM32L4xx_DFP.2.5.0.pack, which can be downloaded at https://www.keil.com/dd2/pack, the memory information for stm32l452 says that the ram size is 0x00020000 = 128kB, but it actually is 0x00028000 = 160kB (SRAM1 + SRAM2).

Using this file for my tooling, gdb is unable to read the values from the stack so I would like to see this fixed. Is this here a good place to report this issue? If not, where should I report it?

[Piranha]

https://www.keil.com/support/bugreport.asp

[TNaum]

Thanks. Does this mean that those ST-related DFP packs are managed by Keil/ARM instead of ST itself?

[Imen.D]

Hello @TNaum​ ,

I have passed your reported issue along to our tools team for review and fix.

Thanks for your contribution.

Imen

[TNaum]

So things turned out to be a little bit more complicated:

The DFP/PDSC contains memory information for the whole subfamily:

<subFamily DsubFamily="STM32L452">
 
...
 
<!-- correct memory layout
 <memory name="SRAM1" access="rwx" start="0x20000000" size="0x00020000" default="1" init="0"/>
 <memory name="SRAM2" access="rwx" start="0x20020000" size="0x00008000" default="1" init="0"/>
 <memory name="SRAM2alias" access="rwx" start="0x10000000" size="0x00008000" default="0" alias="SRAM2"/>
 -->
 
 <memory id="IRAM1" start="0x20000000" size="0x00020000" init="0" default="1"/>
 <memory id="IRAM2" start="0x10000000" size="0x00008000" init="0" default="0"/>
 

It even contains the full information (SRAM2 is aliased at a different address, too) as a commented-out block.

The issues arise when I create a Makefile project with CubeMX. It generates the following line in the linker script:

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 160K

So, depending on the perspective, both the pdsc and the linker script are correct. But in the current state, they are a little bit incompatible: I am using the gdbserver shipped with pyocd which extracts the memory information from the pdsc file so gdb does not let me read addresses above 0x20020000. Unfortunately, that's where the stack ends up using the linker script generated from CubeMX.

I know how to fix those issues for me but it would be nice if those two tools would be more interoperable. Maybe, you can find a way to make this work?

[Imen.D]

Hi @TNaum​ ,

Thank you for your feedback.

I will raise your reported issue to CubeMx team for review and treat accordingly to the priority.

@Nawres GHARBI​ , @Houda GHABRI​ ​Could you please check the issue related to CubeMX.

Imen

[TNaum]

Hi and thanks for your efforts. I'll await your response and the outcome of this issue.

[Houda GHABRI]

Hi @TNaum​ ,

Sorry for the delay.

The issue is reproduced and reported internally to be fixed.

Thanks for raising this issue,

Houda