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.

TMS570LC4357: tms570 with bootloader exception handler question

Part Number: TMS570LC4357

Tool/software:

HI Team:

   

When using the ethernet bootloader, the start address of the application program (LED_Blinky_RM57_At_0x20020) is set to 0x20020. At 0x20020 is the ARM interrupt vector. In my understanding, when the application program (LED_Blinky_RM57_At_0x20020) is running, if an exception occurs, the ARM processor should execute the interrupt vector at the start position of 0x0 by default (which should be the code in the bootloader). My questions are:

  1. Can the TMS570 set the CPU register to ensure that the ARM can execute at 0x20020 when an exception occurs?
  2. If it is not possible to set the ARM exception to execute at the interrupt vector at 0x20020, then how are these exceptions such as undefEntry, svcEntry, prefetchEntry, and dataEntry handled in the application?

This is part of the content of HL_sys_link.cmd in LED_Blinky_RM57_At_0x20020:(HL_sys_link.cmd)

MEMORY
{
/* USER CODE BEGIN (2) */
/* USER CODE END */
VECTORS (X) : origin=0x00020020 length=0x00000020
FLASH0 (RX) : origin=0x00020040 length=(0x001FFFE0-0x20040)
FLASH1 (RX) : origin=0x00200000 length=0x00200000
STACKS (RW) : origin=0x08050000 length=0x00001500
RAM (RW) : origin=0x08051500 length=(0x00080000-0x51500)

/* USER CODE BEGIN (3) */
/* USER CODE END */
}

   

This is part of the content of HL_sys_intvecs.asm in LED_Blinky_RM57_At_0x20020:

.sect ".intvecs"
.arm

;-------------------------------------------------------------------------------
; import reference for interrupt routines

.ref _c_int00
.ref phantomInterrupt
.def resetEntry

;-------------------------------------------------------------------------------
; interrupt vectors

resetEntry
b _c_int00
undefEntry
b undefEntry
svcEntry
b svcEntry
prefetchEntry
b prefetchEntry
dataEntry
b dataEntry
b phantomInterrupt
ldr pc,[pc,#-0x1b0]
ldr pc,[pc,#-0x1b0]

Sincerely thank you 

  • Hi Qing Yu,

    Can the TMS570 set the CPU register to ensure that the ARM can execute at 0x20020 when an exception occurs?

    You are correct,

    It can't execute the 0x20020, if any exception occurs then it will execute only the bootloader exception table.

    If it is not possible to set the ARM exception to execute at the interrupt vector at 0x20020, then how are these exceptions such as undefEntry, svcEntry, prefetchEntry, and dataEntry handled in the application?

    No, they are not handled by the application.

    If you want you can remove them, however i will suggest you keep the "resetEntry" related exception.

    This is because,

    if you verify the application code, at the starting of the flash (after vectors) that is 0x20040 location consists of the " muxInit" function not "_c_int00" function.

    So, i mean if you try to call the "0x20040" address directly without depending on the exception vector table then 'muxInit" will get called right, i mean this function should not be the starting point because this function will not call the main function of the application, so if we call this function directly our code will not run properly.

    The solution for this issue is in two ways:

    1. We should at least keep the reset vector of the application:

    This is easiest way, and if in future there is any additional code added in the functions before the "_c_int00" will not affect the application jump.

    2. We can directly call the address of _c_int00 from bootloader and can remove the vectors table in application, like in this case it is 0x23B28

    But i think if we do like this then, if any code added to the any of the functions that are before the "_c_int00" that will change the start address of this function, so care must be taken and should need to verify the address of "_c_int00" should need to use same address in bootloader.

    --

    Thanks & regards,
    Jagadish.