• State Resolved
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 114 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS570LC4357: uC/OS-III simple Blink Application with CAN Bootloader stuck in OS_CPU_ExceptHndlr

Bitwise_GURU
Prodigy 10 points
Part Number: TMS570LC4357

Tool/software:

I am currently working on integrating an application based on uC/OS-III (Micrium) with a CAN-based bootloader on a TMS570LC43x LaunchXL2 development kit.

The application is a simple LED blinking demo. When programmed directly (without the bootloader), it runs correctly and the LED blinks as expected. However, when flashed via the bootloader (after modifying intvects.asm and link.cmd), the application fails to start and execution gets stuck in OS_CPU_ExceptHndlr.

I have already checked the forum for similar issues and found [this discussion]. In my case, however, execution halts earlier in the process, specifically before reaching the first OSTimeDly call.

Setup Details:

  • MCU: TMS570LC43x (LaunchXL2 DevKit)

  • OS: uC/OS-III (Micrium)

  • Application: Simple LED blinking task

  • Bootloader: CAN-based (forked from TI TMS570LC43xx example)

Observed Behavior:

  • Direct flashing: Application runs normally (LED blinks as expected).

  • Flashing via bootloader: Application does not start (LED does not blink, stuck in OS_CPU_ExceptHndlr).

Questions / Support Needed:

  1. Are there known considerations or limitations when using uC/OS-III with a bootloader on TMS570 devices?

  2. Could this behavior be related to vector table relocation, startup code modifications, or the VIM (interrupt) dispatcher configuration issue?

  3. What is the recommended approach to ensure task scheduling and system tick initialization work properly when the application is launched via a bootloader?

  4. Are there any reference examples, documentation, or guidelines for adapting uC/OS-III startup code to work reliably behind a bootloader on Cortex-R devices?

Thank you in advance for your support.

source_app_BL.zip

  • +1
    TI__Guru 70131 points

    Hi,

    Based on the provided technical documents, the issue you are experiencing is likely related to the application's memory map and the handling of exception vectors when the application is launched by the bootloader. The uC/OS-III kernel relies on exceptions like the Supervisor Call (SVC) for its operation, and these must be correctly forwarded from the bootloader to the application.

    Here is a detailed explanation of the considerations and recommended approach for using a bootloader with an application on a Hercules TMS570 microcontroller.

    Creating an Application for Use With the Bootloader

    To be launched by the bootloader, the application firmware must be compiled and linked to reside at a specific offset in flash memory, leaving the lower memory space for the bootloader. The default starting address for the application is 0x10020.

    This requires modifying the application's linker command file to adjust the memory map.

    Linker Command File Memory Map

    The application's linker file should define the memory regions as follows:

    MEMORY { VECTORS (X) : origin=0x00010020 length=0x00000020 /*sector 4/5 are used for application */ FLASH_CODE (RX) : origin=0x00010040 length=0x80000-0x40 fill=0xFFFFFFFF FLASH0 (RX) : origin=0x00018000 length=0x00200000 FLASH1 (RX) : origin=0x00200000 length=0x00200000 STACKS (RW) : origin=0x08000000 length=0x00001500 RAM (RW) : origin=0x08001500 length=0x0007EB00 }

    Linker Command File Section Configuration

    The .intvecs section, which contains the application's exception vector table, must be placed at the beginning of the VECTORS memory region.

    SECTIONS { .intvecs: { } > VECTORS .text align(32) : { } > FLASH_CODE .const align(32) : { } > FLASH_CODE .cinit align(32) : { } > FLASH_CODE .pinit align(32) : { } > FLASH_CODE .bss : { } > RAM .data : { } > RAM .sysmem : { } > RAM }

    Exception Vector Table Handling

    The ARM Cortex-R architecture has a fixed exception vector table at the beginning of memory (0x00000000), which is occupied by the bootloader. The reset vector must point to the bootloader's entry point. For other exceptions critical to an OS, such as UNDEF, SWI/SVC, PABT, and DABT, the bootloader's vector table must be configured to transfer control to the application's corresponding exception handlers.

    A recommended solution is to modify the bootloader's exception vector table to branch directly to the application's handlers. The provided example uses an application start address of 0x10020. The bootloader's vector table branches to the corresponding addresses in the application space.

    Bootloader Vector Table Example (.intvecs)

    ; application start address is 0x10020 b _c_int00 ; 0x00 Reset vector points to bootloader start b #0x10018 ; 0x04 UNDEF; application start address - 0x08 b #0x10018 ; 0x08 SVC; application start address - 0x08 b #0x10018 ; 0x0C PABT; application start address - 0x08 b #0x10018 ; 0x10 DABT; application start address - 0x08 reservedEntry b reservedEntry ; 0x14 ldr pc, [pc, #-0x1b0] ; 0x18 IRQ ldr pc, [pc, #-0x1b0] ; 0x1C FIQ

    Important Note on Interrupts (IRQ/FIQ): The VIM loads the addresses for IRQ and FIQ handlers directly into the PC. Therefore, it is not necessary to redirect the IRQ and FIQ vectors in the bootloader's vector table. Your application is responsible for configuring the VIM for its own interrupts (like the OS system tick) after it starts.

    Bootloader Execution and Handoff

    The bootloader performs several actions before transferring control to the application, which may affect the application's startup code.

    • Interrupts Disabled: The example bootloader code disables interrupts before it branches to the application. Your application must initialize its own interrupt environment (VIM) and re-enable interrupts as required. Failure to do so before an interrupt source (like the OS tick timer) is enabled could lead to an exception.
    • MCU Mode: The bootloader operates in Supervisor mode. The application code will be entered in this mode.
    • Clock Configuration: The bootloader configures and maintains the MCU clock settings. For the TMS570LCx, the system clock (HCLK) is set to 150 MHz.

    Reference Examples and Documentation

    The application report itself serves as the primary documentation for this process. Furthermore, the report provides a link to download the project collateral and source code, which includes the bootloader project and can serve as a reference.

    By ensuring your application's linker script is correctly configured for memory relocation and that the bootloader's vector table properly forwards exceptions like SVC to your application, you should be able to resolve the issue of the application getting stuck in OS_CPU_ExceptHndlr.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 10 points

    Hello Jagadish,

    I appreciate your thorough explanations. I’ll verify my setup again and make sure to consider your recommendations.

    Thanks & regards,