Closed mikewolfram closed 4 years ago
Found a place, in tools/generator/dfg/stm32/stm.py:
'f7': {
'start': {
'flash': 0x08000000,
'dtcm': 0x20000000,
'itcm': 0x00000000,
'sram': 0x20010000,
'backup': 0x40024000
},
'model': [
{
'name': ['22', '32', '23', '30', '33', '45', '46', '50', '56', '65', '67', '68', '69', '77', '78', '79'],
'memories': {'flash': 0, 'itcm': 16*1024, 'dtcm': 64*1024, 'sram1': 0, 'sram2': 16*1024, 'backup': 4*1024}
}
]
},
Is that the right location?
According to STMCUFinder the F76x and F77x have 128kB, all other F7 only 64kB DTCM.
Yes, that's the right location. I'm sorry for the bugs, but this info isn't part of CubeMX, so I had to add it manually. This is the reason I really don't like it.
No worries, nobody's perfect.
Changing the size of the DTCM would that automatically adjust the start address of SRAM?
No I don't think so. The algorithm is at the bottom of that file, it may require an extension to allow for custom start addresses per table entry.
Ugh, it's a mess:
The pic is a bit misleading. The data from STMCUFinder looks more clear to know which F7 has which RAMs.
Hunting down my issue with memory corruptions I figured out that the XML of the STM32F76x devices have wrong entries for the memories:
But the DTCM is actually 128kB, which would shift the addresses of SRAM1/SRAM2 too.
If you could point me to the right location to fix it...