search

modm-io / modm-devices

Curated device data for all AVR and ARM Cortex-M devices
https://blog.salkinium.com/modm-devices
Mozilla Public License 2.0
50 stars 28 forks source link

SRAM incorrect for stm32g4 series devices #85

Closed twast92 closed 2 years ago

twast92 commented 2 years ago

I did some digging to figure out why the modm generated openocd.cfg crashes when flashing my STM32G491 device (with RTT enabled). Turns out it tries to zero out more SRAM than the device actually has! So I had a look at the device files for this series and found that the SRAM1 size is 112KB https://github.com/modm-io/modm-devices/blob/0a6b13d55ffe18f58d26a50d6974d329d2633273/devices/stm32/stm32g4-71_91_a1.xml#L77 The reference manual specifies that all category 3 and 4 devices have 80KB of SRAM1. image

The source of the problem is twofold: First there is a problem with the raw_device_data for this line of devices (STM32G491). The \<Ram> section specifies 128KB of total SRAM when it should be 112KB according to the reference manual. The second problem is that the main_sram is calculated without taking the CCM SRAM into account resulting in more SRAM1 than is actually available. https://github.com/modm-io/modm-devices/blob/0a6b13d55ffe18f58d26a50d6974d329d2633273/tools/generator/dfg/stm32/stm.py#L783-L794 This second problem is present for all STM32G4 devices and probably any other that specifies SRAM in this way (ST apparently can't decide on a standard for these things 🤷‍♂️)

I'm unsure if it is intended that the CCM SRAM is counted as part of SRAM1 or if it truly is a problem. In either case, I hope you can clarify.

As an added bonus, I found that the STM32G471 devices are lobbed in with the category 4 devices when it should be in the category 3 devices https://github.com/modm-io/modm-devices/blob/0a6b13d55ffe18f58d26a50d6974d329d2633273/tools/generator/dfg/stm32/stm.py#L438 image

I can make a PR with whatever changes are required if that is desired :)

salkinium commented 2 years ago

Interesting bug! Unfortunately we haven't found a reliable way to extract the memory layout from the CubeMX database, so we've resorted to this manual hacky way.

IIRC the <Ram> tag is the sum of only the SRAM memories and excludes CCM and *TCM memories, hence it not being subtracted from it. So I guess the easiest fix is to patch the raw data via the patch mechanism. You can also open an issue with STMicro to get clarification and a fix upstream (eventually).

Please open a PR with your fixes, then we can see what changed in more detail. The grouping is also manually estimated, so probably just wrong as you noticed.

twast92 commented 2 years ago

IIRC the tag is the sum of only the SRAM memories and excludes CCM and *TCM memories, hence it not being subtracted from it.

If that is the case, then the \<Ram> figure only makes sense if it counts the parity bits as part of the total SRAM size. STs reference manual does not specify that this is the case though, so I am still slightly puzzled with these numbers.

I will open a PR with some patches for the raw_device_data 👍