• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 29 subscribers
  • Views 174 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

EK-TM4C1294XL: Eth bootloader update vector fails

EK-TM4C1294XL: KCPDT Serial Bootloader jumps NmiSR()

Genatco
Guru 54057 points
Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: TM4C1294KCPDT, LM3S8971

Tivaware 2.1.2.111 driverlib & Serial Bootloader (SBL) projects:

KCPDT tool chain build of BootLoader copies itself to SRAM (0x2000.0000) and launches flash application from (0x4000) via EK-TM4C1294XL launch pad without issues.

However the same SBL build when loaded to TM4C1294KCPDT custom PCB with 512Kb flash does not seem to copy Flash SBL into SRAM, rather assets NmiSR() via bl_startup_ccs.s. Otherwise the KCPDT application runs from flash 0x0000 on custom PCB without issues. 

The bl_link.cmd layout (below) is the same on both MCU class. Why will KCPDT not copy Flash loaded SBL into same SRAM address range KCPDT?

/* System memory map */

MEMORY
{
FLASH (RX) : origin = 0x00000000, length = 0x00010000
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* Section allocation in memory */

SECTIONS
{
GROUP
{
.intvecs
.text
.const
.data
} load = FLASH, run = 0x20000000, LOAD_START(init_load), RUN_START(init_run), SIZE(init_size)

GROUP
{
.bss
.stack
} run = SRAM, RUN_START(bss_run), RUN_END(bss_end), SIZE(bss_size), RUN_END(__STACK_TOP)
}

**************************************************************************************

Application KCPDT:

/* The starting address of the application. Normally the interrupt vectors */
/* must be located at the beginning of the application. */
#define APP_BASE 0x00004000 //SBL=0x00004000, 16384 bytes.
#define RAM_BASE 0x20000000


/* System memory map */

MEMORY
{
FLASH (RX) : origin = 0x00000000, length = 0x00080000 /* FLASH KCPDT 80k=524288KB, NCPDT 100k=1,048,572 */
SRAM (RWX) : origin = 0x20000000, length = 0x00040000 /* SRAM .bss,.data */
}

/* The following command line options are set as part of the CCS project. */
/* If you are building using the command line, or for some reason want to */
/* define them here, you can uncomment and modify these lines as needed. */
/* If you are using CCS for building, it is probably better to make any such */
/* modifications in your CCS project and leave this file alone. */
/* */
/* --heap_size=0 */
/* --stack_size=8192 */
/* --library=rtsv7M4_T_le_eabi.lib */

/* Section allocation in memory */
SECTIONS
{
.intvecs: > APP_BASE
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH

.vtable : > RAM_BASE
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}

__STACK_TOP = __stack + 512;

  • +1
    TI__Guru*** 128095 points

    Hi Gl,

    I haven't been able to dig into this one much yet but two initial questions here: 

    1) Have you verified the boot loader was successfully flashed?

    2) Can you compare the Flash contents to make sure the same code was loaded in both devices?

    Also maybe check Release Notes for any bug fixes regarding this if you are using 2.1.1. Maybe there was an issue that is now resolved: www.ti.com/.../spmu299

  • 0 in reply to Ralph Jacobi
    Guru 54057 points

    Hi Ralph,

    It seems the KCPDT was assumed to be the same as NCPDT but the SBL Thumb instructions are not doing the same copy relocating SBL into SRAM 0x2000.0000.  Or the KCPDT.cmd pointers to Flash top 512Kb are different than expected in SBL Thumb codes bl_startup_ccs.s.  

    I used LM-Flash to load application to 0x0000.4000 and SBL to 0x0000.0000 but CCS debug Break Point bl_emac.c or main.c (uart2) ping pongs between reset __Cint00 and Delay. They never copy application vector table 0x0000.40000 or calls application 0x0000.4000.

       cbz     r0, CallApplication

  • 0 in reply to Ralph Jacobi
    Guru 54057 points

    BTW: KCPDT can issue Hardware reset from LM-Flash any amount of times and the LED's, relays assert as expected. One idea is for TI to pull NCPDT from EK-TM4C1294XL launch pad install KCPDT part and actually test the RA2 Silicon works as expected Nerd

  • 0 in reply to Genatco
    Guru 54057 points

    Another point KCPDT flash being 512Kb and the VTABLE register offset value (hw_nvic.h) is not set on 1024 byte boundary. The NCPDT is relocating the BL vector table via VTABLE offset in a Flash region, seemingly not SRAM as it should. Otherwise the simple Blinky code KCPDT should launch after BL relocates with his vector table, leaving the application vector table at 0x4000. 

    Seemingly thumb code issue is why NCPDT Bootloader works with Blinky at VTABLE offset (0x4000) but the KCPDT will not. The privileged SW being Thumb code instructions seem to cause VTABLE offset boundary violation KCPDT. Hence BL acts dead if it does not turn on LED's before it fails to find the application vector table offset in SRAM.

    Datasheet Page 119

    On system reset, the vector table is fixed at address 0x0000.0000. Privileged software can write to the Vector Table Offset (VTABLE) register to relocate the vector table start address to a different memory location, in the range 0x0000.0400 to 0x3FFF.FC00 (see “Vector Table” on page 119). Note that when configuring the VTABLE register, the offset must be aligned on a 1024-byte boundary.

    ;;
    ;; Set the vector table pointer to the beginning of SRAM.
    ;;
    movw r0, #(NVIC_VTABLE & 0xffff)
    movt r0, #(NVIC_VTABLE >> 16)
    movs r1, #0x0000
    movt r1, #0x2000
    str r1, [r0]

    ;;
    ;; Set the return address to the code just copied into SRAM.
    ;;
    orr lr, lr, #0x20000000 

    ;;
    ;; Return to the caller.
    ;;
    bx lr
    .endasmfunc

  • +1 in reply to Genatco
    Guru 54057 points
    Genatco said:
    Seemingly thumb code issue is why NCPDT Bootloader works with Blinky at VTABLE offset (0x4000) but the KCPDT will not

    The SBL call to load the NVIC_VTABLE offset via indirect memory addressing Thumb code is not working for  KCPDT, FLASH length=0x00080000, origin=0x00004000.

    That call gets the table at NVIC offset of the applications Flashed Vtable. Need to add text to PDF, Note to subtract the origin from the Length. Oddly that is not required for NCPDT Length=0x000100000. Nor was it required for LM3S8971 ~.cmd file and the NVIC_VTABLE offset address contents seem to be relocated with the application. It doesn't matter the compiler LTS or older, looses flash length when origin is moved upward.

  • 0 in reply to Ralph Jacobi
    Guru 54057 points

    Hi Ralph,

    Thanks for the link to PDF it was very enlightening in many areas read the entire PDF. The SBL user PDF has no mention to modify tool chain Linker.cmd FLASH length vector to be the absolute application end address. Changes were made by TI development departments and not followed up by manifest changes.

    The project MCU ~cmd file should only require the target start address of the NVIC_TABLE offset register contents matches flash loaded application start address. And not the FLASH length to be reduced as to offset the applications vector table Flash load start address relative to the tool chain variant flash memory end address length.

    The entire Flash range of the tool chain variant MCU class should be usable by the application and not reduced by the addition of serial boot loader in any way.