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.

CORTEX M4 HARD FAULT PROBLEM USING A PROPRIETARY BOOTLOADER

Other Parts Discussed in Thread: TM4C1294NCPDT

when i download an application sometimes it ends up in a fault interrupt

the situation:
TI Cortex M4 TM4C1294NCPDT
IAR compiler (7.40.1)
user written bootloader with lwip-library to download a new application over network
no RTOS

the problem:
when I download an application with the bootloader it ends in a fault interrupt when the __iar_program_start() is called
if i start the same application at the same flash location (0x40000) using the debugger, it works fine

when i read the registers i get the following values:
HARD FAULT STATUS REG: Forced = 1
ICSR: Vector = 0x03
FAULT STATUS REGISTER: Invalid State = 1
PROGRAM STATUS REG: Thumb = 1


the problem seems to depend on the amount of memory used!!!
if i increase the size of an array it fails, otherwise i can start the downloaded code.


works:

"P2": 0x12cd0
P2 s0 0x20000000 0x4 <Init block>
.data inited 0x20000000 0x1 shuttle_flash.o [1]
.bss zero 0x20000004 0x12360 shuttle_flash.o [1]
.bss zero 0x20012364 0xc8 shuttle_flash.o [1]
.bss zero 0x2001242c 0x94 shuttle_flash.o [1]
.bss zero 0x200124c0 0x4 shuttle_flash.o [1]
.bss zero 0x200124c4 0x4 shuttle_flash.o [1]
.bss zero 0x200124c8 0x4 shuttle_flash.o [1]
.bss zero 0x200124cc 0x1 shuttle_flash.o [1]
.bss zero 0x200124cd 0x1 shuttle_flash.o [1]
.bss zero 0x200124ce 0x1 shuttle_flash.o [1]
.noinit uninit 0x200124d0 0x800 startup_ewarm.o [1]
- 0x20012cd0 0x12cd0

pui32Stack 0x200124d0 0x800 Data Lc startup_ewarm.o [1]


fails:
"P2": 0x12d60
P2 s0 0x20000000 0x4 <Init block>
.data inited 0x20000000 0x1 shuttle_flash.o [1]
.bss zero 0x20000004 0x123f0 shuttle_flash.o [1]
.bss zero 0x200123f4 0xc8 shuttle_flash.o [1]
.bss zero 0x200124bc 0x94 shuttle_flash.o [1]
.bss zero 0x20012550 0x4 shuttle_flash.o [1]
.bss zero 0x20012554 0x4 shuttle_flash.o [1]
.bss zero 0x20012558 0x4 shuttle_flash.o [1]
.bss zero 0x2001255c 0x1 shuttle_flash.o [1]
.bss zero 0x2001255d 0x1 shuttle_flash.o [1]
.bss zero 0x2001255e 0x1 shuttle_flash.o [1]
.noinit uninit 0x20012560 0x800 startup_ewarm.o [1]
- 0x20012d60 0x12d60

pui32Stack 0x20012560 0x800 Data Lc startup_ewarm.o [1]

  • some more information:

    before the bootloader starts the application it:
    - disables master interrupt
    - disables watchdog reset
    - resets all peripherials
    - sets interrupt vector base adr


    // reset all used peripherials
    .........
    SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
    SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);

    // set vector adr in NVIC register, use interruptvectors from application now!
    HWREG(NVIC_VTABLE) = Get_VectorAddress();

    // Branch to the specified address.
    ((void (*)(void))startAdr)();
  • May I note that your writing does not reveal if you've read, understood & complied w/vendor's, "Best Ever Boot-Loader Application Note - w/Code Examples." This note is terrific - highly detailed - sure to assist - clarify - guide.

    You'll note this w/in the "Sticky area" atop these (non-adhesive) more general, forum postings.
  • Hello Koppi,

     Never having used the bootloader I can only guess at this. So 2 guesses:

    1) Is the page in the TM4C1294NCPDT revB datasheet detailing 'Register 68: Boot Configuration (BOOTCFG), offset 0x1D0' any good to you?

    2) Is the difference between the 2 startups what happens to the stack pointer? Maybe the debugger programs the flash and when the application runs the stack pointer gets pulled from 0x20004000 with the program counter being pulled from 0x20004004 and pointing to  __iar_program_start.

    What happens to the bootloaded version? Is the stack pointer being set? As I say, it's a guess.

  • Thank you for your help!!!
    Finaly I didnt initalize the stack pointer - what automatically is done by the core during a reset or is handled by the debugger.