[SOLVED] Created code not correct for given memory map / 4 bytes off

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

  • [SOLVED] Created code not correct for given memory map / 4 bytes off

    Hi,

    after one of my rarely touched projects wasn't working any longer properly (although it did compile without errors), I was able to reproduce the issue even by using the sample project from the STM32F4xx package:

    - Create a new solution/project with STM32F4xx package "C/C++ executable for STM32F4xx"
    - Choose target STM32F405RG
    - Settings: Compiler: Either GCC or SEGGER, Linker: SEGGER
    - Change the main.c to this to verify the rand() function:

    EDIT: With SEGGER compiler the problem doesn't show up like this, because the memory regions are setup differently, but the memory address used by rand() is still wrong by 4 bytes.

    //-----------------------

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    int main(void) {
    int i, r;
    static char some_data[10000];

    for (i = 0; i < 100; i++) {
    r = rand();
    memset(some_data, 0, 10000);
    printf("Hello World %d!\n", r);
    }
    do {
    i++;
    } while (1);
    }

    //-----------------------

    The program should output random numbers, but the actual output is:

    Hello World 0!
    Hello World 0!
    ...


    After some investigation I noticed the created memory map in the .map file doesn't match the what the created code is actually doing:

    In the .map file I have:

    10000000-10000003 __SEGGER_RTL_rand_next 4 4 Init RW intops.o (libc_v7em_fpv4_sp_d16_hard_t_le_eabi_balanced.a)
    10000004-10002713 some_data.0 10 000 4 Zero ZI main.o

    That means the rand() function is using 0x10000000-0x10000003 for some purpose, the array some_data is at location 0x10000004-0x10002713.

    In the created code, the rand() function is infact using memory 0x10000004-0x10000007 erroneously which causes a collision with the memory of the array. Due to the fact that the code is zeroing the array, the output of rand() is always 0.

    So for (to me) unknown reason, there is a memory offset of 4 between the memory map and the memory used by the rand() function in the C lib.

    Please find the screenshot I did during debugging attached.

    The rand() function accesses [r0, r1] (indirect), which is 0x0ffffffc + 0x00000008 = 0x10000004 (!!!) in this case, and it is wrong (should be 0x10000000).

    Maybe this is related to a wrong offset returned by the __aebi_read_tp function, but how could it be fixed? Is there anything wrong on my side / settings?

    I checked this with Embedded Studio 6.40 as well as with 7.10a.

    Regards
    Markus

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

  • Hello,

    Thank you for your inquiry.
    The reported issue is related to the rand() function using so called thread local storage.

    In your older project most likely no tls handler is implemented and thus function __aeabi_read_tp will return an incorrect pointer to the tls variables.
    For more information about tls in Embedded Studio see here:
    wiki.segger.com/Thread-Local_Storage

    To fix this all you need to do is to use the latest STM32F4xx package from the ES package manager and create a new project with it with the latest Embedded Studio version.
    Then all startups and handlers that are required for this should be set up correctly and your sample application will work as expected and print random numbers.

    Can you confirm that creating a new project with the latest files works for you as well?

    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.
  • SEGGER - Nino wrote:


    To fix this all you need to do is to use the latest STM32F4xx package from the ES package manager and create a new project with it with the latest Embedded Studio version.
    Then all startups and handlers that are required for this should be set up correctly and your sample application will work as expected and print random numbers.

    Can you confirm that creating a new project with the latest files works for you as well?
    No, it is still not ok. Please find the screenshots attached:

    - Version is Embedded Studio 7.10a, all packages up-to-date
    - Create new STM32F4xx project, STM32F405RG target, C/C++ executable
    - Leave everything as default, only change debugging target to Simulator in Project options
    - You can see in the generated code stil the offset is wrong
    Images
    • 2023-01-15 18_15_57-SEGGER Embedded Studio for ARM V7.10a (64-bit).png

      47.79 kB, 911×693, viewed 282 times
    • 2023-01-15 18_19_10-Window.png

      149.01 kB, 1,920×1,132, viewed 250 times
    • 2023-01-15 18_20_06-Window.png

      109 kB, 1,920×887, viewed 295 times
  • Hello,

    yes you are correct. The ST package linker script unfortunately has not been updated yet.
    In the linker script you should find the following line:

    C Source Code

    1. define block tls { block tbss, block tdata };


    replace it with:

    C Source Code

    1. define block tls with fixed order { block tbss, block tdata };


    Then the tls offset should be calculated correctly.
    Can you confirm.

    This will be fixed in the next package update and the wiki article will additionally explain in future what prerequisites are needed for a working tls setup.

    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.