[SOLVED] MEM_MAP.c error with STM32G071

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

  • Hello,

    Thank you for your inquiry.
    The error comes from the STM32G7 series having different alias addresses that can be remapped by the user.
    Most likely your application in IAR links code to address 0x0 which can be either RAM, Flash or system memory.
    The real Flash address is at 0x08000000 and RAM is at 0x20000000.
    So you can either link your application to 0x08000000 instead or set the alias region to 0x0.
    This can be done with exec command "map region".
    The call would be "map region 0x0-0x1ffff A 0x08000000 0x20000".
    How to use exec commands is explained in the J-Link user manual UM08001.

    Best regards,
    Nino
    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.
  • Thanks for your reply.

    In fact I link my application to 0x08000000, same error occurred with sample code shipped with STM32Cube.
    Here is my linker script:

    Source Code

    1. /*###ICF### Section handled by ICF editor, don't touch! ****/
    2. /*-Editor annotation file-*/
    3. /* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
    4. /*-Specials-*/
    5. define symbol __ICFEDIT_intvec_start__ = 0x08000000;
    6. /*-Memory Regions-*/
    7. define symbol __ICFEDIT_region_ROM_start__ = 0x08000000;
    8. define symbol __ICFEDIT_region_ROM_end__ = 0x0801FFFF;
    9. define symbol __ICFEDIT_region_RAM_start__ = 0x20000000;
    10. define symbol __ICFEDIT_region_RAM_end__ = 0x20008FFF;
    11. /*-Sizes-*/
    12. define symbol __ICFEDIT_size_cstack__ = 0x400;
    13. define symbol __ICFEDIT_size_heap__ = 0x200;
    14. /**** End of ICF editor section. ###ICF###*/
    15. define memory mem with size = 4G;
    16. define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];
    17. define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];
    18. define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };
    19. define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };
    20. initialize by copy { readwrite };
    21. do not initialize { section .noinit };
    22. place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
    23. place in ROM_region { readonly };
    24. place in RAM_region { readwrite,
    25. block CSTACK, block HEAP };
    26. export symbol __ICFEDIT_region_RAM_start__;
    27. export symbol __ICFEDIT_region_RAM_end__;
    Display All
    Another bug is as soon as RTT client is opened, MCU goes into NMI interrupt. I'm also going to ask technical support of IAR, since maybe they did something wrong.

    The post was edited 1 time, last by pasnew ().

  • Hello,

    we tried to reproduce the RTTClient and the alias issue when linking to 0x080000000 but both were not reproducible with our IDE Embedded Studio.
    You can find a reference project for Embedded Studio attached.
    Could you provide a J-Link log of the failing session with IAR?
    wiki.segger.com/Enable_J-Link_log_file

    Using RTTClient and debugging at the same time worked without any issues with Embedded Studio, see picture attached.
    Does the reference project work on your target board as well?
    Does debugging work with the IAR output file when using Ozone instead of IAR debugger?
    segger.com/products/development-tools/ozone-j-link-debugger/

    Best regards,
    Nino
    Images
    • Capture.PNG

      131.45 kB, 1,328×1,202, viewed 456 times
    Files
    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.
  • In the attachment there are:
    • iar fail.log : J-Link log of the failing session with IAR, we can see the MemMap error message.
    • ozone.log : Same error when debugging iar output file with OZone.
    • test.zip : Iar output file.
    • embedded studio.zip : embedded studio log. No MemMap error, but as soon as I click run MCU enters NMI.
    Both STM32G071CBT6 minimal system board (no peripherals, only 10uF + 100nF decouple capacitors) and NUCLEO-G071RB(on board ST-Link disabled by jumper) are tested.
    Files
    • ozone.log

      (13.23 kB, downloaded 328 times, last: )
    • embedded studio.zip

      (17.14 kB, downloaded 251 times, last: )
    • iar fail.log

      (41.92 kB, downloaded 269 times, last: )
    • test.zip

      (2.73 kB, downloaded 242 times, last: )
  • I found the corrupt of the NMI interrupt, it's cause by SRAM parity check I enabled previously in another project. Since by default RAM is not erased at startup, parity error could occur. So I reset option bytes.

    Following are 2 memery map at address 0 using ST-Link+IAR & J-Link+Embedded Studio.

    The post was edited 2 times, last by pasnew ().

  • Hello,

    Thank you for providing the logs.
    Both the IAR and Ozone log show that the application is loading to 0x0 instead of 0x080000000, so the application is not linked to 0x080000000 at all...

    Please understand that we can't put more time into this as this is clearly an issue with the IAR project setup or how IAR handles Flash loading addresses.

    For clarification, the provided Embedded Studio example project works out of the box right?

    Of course it is not showing any memory at 0x0 as it is linking the application to 0x080000000.


    Best regards,

    Nino
    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.
  • Hi,

    As you can see the memory viewer of Embedded Studio, it failed to access memory at address 0x0. This is not an intended behavior, as the Flash content of 0x08000000 (or system memory, depend on boot0 pin) is mapped at address 0x0 at boot time (refer to RM0444, section 2.5 Boot configuration, page 58). So this is definitely not a IAR issue.


    Best regards,

    The post was edited 2 times, last by pasnew ().

  • Hello,

    pasnew wrote:

    the Flash content of 0x08000000 (or system memory, depend on boot0 pin) is mapped at address 0x0 at boot time (refer to RM0444, section 2.5 Boot configuration, page 58).
    Yes we know, and this is exactly why IARs behaviour is not correct here as it assumes the position of boot0 pin. As you wrote yourself at 0x0 can be anything depending on the pin setting.
    This is not a fixed setting and will vary from customer to customer, so we will not assume that at 0x0 Flash might be aliased as this will not be the case for all setups and create only issues in the long run (as we can see proven by the existence of this thread).
    So in short:
    Embedded Studio default project works out of the box.
    EWARMs default project does not.
    This should make clear which IDE is handling optional settings correctly and which is not.

    As the initial inquiry has be answered this thread will be closed now.

    Best regards,
    Nino
    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.
  • Correction:
    It was a problem in the J-Link SW that has been fixed in recent versions (V6.48 and later).
    There was an internal misunderstanding. It was not a problem on the IAR EWARM side.
    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.