This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM57L843: MPU make data abort exception after flash the application through the bootloader

Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

I have an application running on FreeRTOS that works smoothly as a standalone program. However, when I flash it through the bootloader, reboot, and jump to the application from the bootloader, the system raises a data abort exception after the scheduler starts. This exception occurs at the beginning of one of the tasks, specifically at the line where I define and initialize a small array.

After thorough debugging, I identified that the issue is related to the Memory Protection Unit (MPU). Disabling the MPU in FreeRTOS resolves the issue. My question is, what could be causing the MPU to malfunction when jumping from the bootloader to the application, and why does this issue not occur when the application is flashed directly without the bootloader?

  • Hi Kamyar,

    Can you please share the linker cmd files for both bootloader and application? So that i can quickly verify them.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    here is the bootloader linker file : 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /*----------------------------------------------------------------------------*/
    /* Linker Settings */
    --retain="*(.intvecs)"
    /* USER CODE BEGIN (1) */
    /* USER CODE END */
    /*----------------------------------------------------------------------------*/
    /* Memory Map */
    MEMORY
    {
    /* USER CODE BEGIN (2) */
    /* USER CODE END */
    VECTORS (X) : origin=0x00000000 length=0x00000020 vfill = 0xffffffff
    FLASH0 (RX) : origin=0x00004000 length=0x001FBFE0 vfill = 0xffffffff
    FLASH1 (RX) : origin=0x00200000 length=0x00200000 vfill = 0xffffffff
    SRAM (RWX) : origin=0x08002000 length=0x0002D000
    STACK (RW) : origin=0x08000000 length=0x00002000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    And here is the Application linker file : 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /*----------------------------------------------------------------------------*/
    /* Linker Settings */
    --retain="*(.intvecs)"
    /*----------------------------------------------------------------------------*/
    /* Memory Map */
    MEMORY
    {
    /* These configuration settings are required for all SafeRTOS based
    * applications.
    * If the whole build is using ARM mode then VECTORS length can be 0x20.
    * When using thumb mode, 0x80 is required to accommodate the interwork
    * code. */
    VECTORS (X) : origin=0x00010020 length=0x00000080
    KERN_FUNC (RX) : origin=0x000100A0 length=0x0000FF80
    FLASH0 (RX) : origin=0x00020020 length=0x001DFFE0
    FLASH1 (RX) : origin=0x00200000 length=0x00200000
    STACKS (RW) : origin=0x08000000 length=0x00001800
    KERN_DATA (RW) : origin=0x08001800 length=0x00000800
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Kamyar,

    I don't see any major issues with your linker cmd files. However, i don't understand why you are not starting the bootloader code at starting location of flash.

    Why instead of starting from 0x00000020 you are starting it from 0x00004000, what is the purpose of doing this?

    I am also suggesting you refer below thread once:

    Here you can find several working bootloader example codes, so you can just check them once

    (+) [FAQ] TMS570LC4357: Examples and Demos available for Hercules Controllers (E.g. TMS570x, RM57x and RM46x etc) - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish

    Thanks for reviewing.

    To start the bootloader code from 0x4000 instead of 0x20, we need to copy our application's exception vector table into the bootloader's. This requires erasing the first sector each time after flashing new firmware. The RM57L843 does not allow relocating the exception vector table address like the VTOR does in ARM Cortex M series. Is there a way to achieve this? Also, will starting from 0x4000 cause any issues?

  • Kamyar,

     The RM57L843 does not allow relocating the exception vector table address like the VTOR does in ARM Cortex M series. Is there a way to achieve this?

    You are correct, vector relocation is not possible.

    Also, will starting from 0x4000 cause any issues?

    No, it won't cause any issues. Even i created one sample demo and tested it worked without any issues.

    Application_at_0x4000_TEST_RM57.zip

    So, the issue should be something else. I need your complete bootloader and application projects for verification, is it possible to share them? or at least a simplest project with the issue. You can even send through private messages.

    ---
    Thanks & regards,
    Jagadish.

  • Jagadish,

    The application and bootloader each work independently without issues. However, when jumping from the bootloader to the application, a data abort error occurs. It appears that some initializations being done twice—once in the bootloader and again in the application—are causing this problem. Do you have any insights on why this double initialization is causing issues?

  • Hi Kamyar,

    (+) [FAQ] TMS570LC4357: Troubleshooting the Abort Exceptions on Hercules Devices - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    In above FAQ my colleague discussed how to troubleshoot the exception, can you please refer above thread, and can you please try to find out exactly which address causing the exception. And verify the corresponding address in map file and you can find out exactly which function causing the issue.

    --

    Thanks & regards,
    Jagadish.

  • Thanks for the link and it is very helpful. but we already know which line of the code in the application make the issue but we don't know why it is happening.

    that line of the code when we run then application standalone and not through the bootloader it works without any issue.

    As we check these problem are happening when the chip get initiated two times: first in the bootloader and then in the application .

    My question is why it make the problem ?

  • Hi Kamyar,

    Can you please share the screenshot of exactly at which line and which function the issue is occurring?

    And also, i need the HALCoGen MPU configurations for both bootloader and application?

    --
    Thanks & regards,
    Jagadish.