- This topic has 3 replies, 2 voices, and was last updated 2 weeks ago by
.
-
Posts
-
Hello,
The memory sizes in the device selection during the creation of a new embedded project are wrong for the STM32H723ZG MCU. I’ve attached a screenshot.
Also, the linker script contains wrong memory settings.
here is what VisualGDB produces:
MEMORY { FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 1M SRAM (RWX) : ORIGIN = 0x24000000, LENGTH = 128K DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K RAM_D2 (RWX) : ORIGIN = 0x30000000, LENGTH = 32K RAM_D3 (RWX) : ORIGIN = 0x38000000, LENGTH = 16K ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K }and here is what it should be:
MEMORY { ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 320K RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 32K RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 16K }What is the problem with the wrong memory definitions?
Hi,
The memory definitions are automatically parsed from the device definitions inside the original SDKs, and sometimes they don’t match the datasheets. Normally, ST fixes this in the next SDK release. Until then, patching the linker script manually should be a reasonable workaround.
Hi,
Thank you for the fast answer. I’ve done this before, and I was just wondering if I could change the definitions myself.
Hi,
You can just patch the linker script file under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs.
If you want to fix it for multiple devices, you can try regenerating the entire BSP from the STM32 SDKs using our BSP generator. However, it involves some manual setup (e.g. downloading STM32CubeMX) and will download huge SDK packages from ST.
- You must be logged in to reply to this topic.