SRAM incorrect for stm32g4 series devices

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

modm-devices/devices/stm32/stm32g4-71_91_a1.xml

Line 77 in 0a6b13d

The reference manual specifies that all category 3 and 4 devices have 80KB of SRAM1.

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.

modm-devices/tools/generator/dfg/stm32/stm.py

Lines 783 to 794 in 0a6b13d

    
           # Correct RAM size 
        
           main_sram = next( (name for (name, size) in mem_model.items() if size == 0), None ) 
        
           if main_sram is not None: 
        
               main_sram_name = next( ram for ram in mem_start.keys() if main_sram.startswith(ram) ) 
        
               # compute the size from total ram 
        
               mem_model[main_sram] = total_ram 
        
               main_sram_index = int(main_sram.split("sram")[-1]) if main_sram[-1].isdigit() else 0 
        
               for name, size in mem_model.items(): 
        
                   mem_index = int(name.split("sram")[-1]) if name[-1].isdigit() else 0 
        
                   if name.startswith(main_sram_name) and mem_index != main_sram_index: 
        
                       mem_model[main_sram] -= size

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

modm-devices/tools/generator/dfg/stm32/stm.py

Line 438 in 0a6b13d

'name': ['71', '91', 'a1'],

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

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.

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 👍

	# Correct RAM size
	main_sram = next( (name for (name, size) in mem_model.items() if size == 0), None )
	if main_sram is not None:
	main_sram_name = next( ram for ram in mem_start.keys() if main_sram.startswith(ram) )
	# compute the size from total ram
	mem_model[main_sram] = total_ram
	main_sram_index = int(main_sram.split("sram")[-1]) if main_sram[-1].isdigit() else 0
	for name, size in mem_model.items():
	mem_index = int(name.split("sram")[-1]) if name[-1].isdigit() else 0
	if name.startswith(main_sram_name) and mem_index != main_sram_index:
	mem_model[main_sram] -= size