[Solved] Bug report: STM32F3xx CPU support package has incorrect memory map

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [Solved] Bug report: STM32F3xx CPU support package has incorrect memory map

    Hi,
    Just found the new STM32F3xx CPU support package will generate an incorrect memory map of the chip. When I select STM32F334R8 as the target, the auto generated example "Hello world" code will always cause a hard fault when debugging on hardware but runs fine in simulation. I finally found out it's the STM32F334R8Tx_MemoryMap.xml file doesn't give a correct memory map. It has the content:

    Source Code

    1. <!DOCTYPE Board_Memory_Definition_File>
    2. <root name="STM32F334R8Tx">
    3. <MemorySegment name="FLASH1" start="0x08000000" size="0x00010000" access="ReadOnly" />
    4. <MemorySegment name="RAM1" start="0x20000000" size="0x00004000" access="Read/Write" />
    5. </root>

    while an old project created by an older version of SES has the STM32F334R_MemoryMap.xml has the following content:

    Source Code

    1. <!DOCTYPE Board_Memory_Definition_File>
    2. <root name="STM32F334R8">
    3. <MemorySegment name="FLASH1" start="0x08000000" size="0x00010000" access="ReadOnly" />
    4. <MemorySegment name="CCM_RAM1" start="0x10000000" size="0x00001000" access="Read/Write" />
    5. <MemorySegment name="RAM1" start="0x20000000" size="0x00003000" access="Read/Write" />
    6. </root>

    The SP register was initialized to 0x20004000 with the new map file, which will cause a hard fault when a push instruction is executed.

  • There seem to be more issues with the STM32F3xx support package.
    First I tried to create an application for the F3 discovery (F303VCT6), using the provided startup and vector files, and replacing everything else with ported SPL code.
    This application ended up in a hardfault in between the first 5 instructions of SystemInit (the first function called after the reset vector).
    More precisely an IMPRECISERR, with STKERR set (bus fault on stacking for exception entry). The stack address, including the one fetched from the reset vector, seemed fine. Reproduced under Win10 with SES 7.10 and SES 6.22 under Linux.

    I then tried an unmodified project for the same MCU (STM32F303VC), i.e. everything except the target was left at the project wizard defaults.
    This worked fine in SES 6.22 under Linux, but crashed in the SES7.10 Win10 installation.
    Here, it ends up in a hardfault in the third 'RunInit' loop of the '_start' function in SEGGER_THUMB_Startup.s.
    The respective code is:

    Source Code

    1. ldr R4, =__SEGGER_init_table__ // Set table pointer to start of initialization table
    3. L(RunInit):
    5. ldr R0, [R4] // Get next initialization function from table
    7. adds R4, R4, #4 // Increment table pointer to point to function arguments
    9. blx R0 // Call initialization function
    11. b L(RunInit)
    Display All
    The called function is '__SEGGER_init_ctors', where it faults on the first stack access (push {r0-r1} with sp = 0x2000bffc).
    SCB.BFSR is again IMPRECISERR, with STKERR set (bus fault on stacking for exception entry).

  • Hi,

    thank you for your inquiry.

    The packages has recently been updated using the most recent CMSIS files provided by ST.
    Unfortunately the RAM size for some of the subfamilies was set incorrectly, meaning larger than actually available on the device.
    Because of this memory addresses were used which are not actually available on the device.
    As the stack is usually placed at the end of the RAM region, it hard-faults on the first push instruction.

    The package has already been fixed and will be released with the next batch of packages.
    To get notified automatically you can subscribe here: https://www.segger.com/notification/subscribe.php?prodid=196


    Thank you for making us aware of this issue!

    Best regards,
    Sebastian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • > Unfortunately the RAM size for some of the subfamilies was set incorrectly, meaning larger than actually available on the device.
    > Because of this memory addresses were used which are not actually available on the device.
    > As the stack is usually placed at the end of the RAM region, it hard-faults on the first push instruction.

    Ah, ok. Now I see it.
    For my device, the memory map file says:
    <root name="STM32F303VCTx">
    <MemorySegment name="FLASH1" start="0x08000000" size="0x00040000" access="ReadOnly" />
    <MemorySegment name="CCM_RAM1" start="0x10000000" size="0x00002000" access="Read/Write" />
    <MemorySegment name="RAM1" start="0x20000000" size="0x0000C000" access="Read/Write" />
    </root
    In this case, it should be 0x0000A000 (40kB).

    The ST datasheet is a bit confusing here as well.
    It lists two sizes in one location, 32kB and 40kB. Only the "ordering information" chapter lists the actual sizes for specific devices.

    Manually updating the memory map file fixes it, too.