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.

TMS320F28P650DH: Report Interrupt PIE Vector Error when a boot jump to the app

Part Number: TMS320F28P650DH
Other Parts Discussed in Thread: UNIFLASH,

I created a boot from 0x80000 to 0x86FFF.

App1 starts from 0x87000 to 0xBFFFF controlled by CPU1.

App2 starts from 0x100000 to 0x11FFFF controlled by CPU2.

I used uniflash.exe downloaded the whole HEX file. Including the boot, app1 and app2.

The boot can jump to app1 and app2 correctly. App1 and app2 work perfectly.

The problem happened in this way:

  1. App reset and starts from boot.
  2. Boot read BANK1 data and write them into BANK0 (from 0x87000 to 0x8FFFF), BANK4 (from 0x100000 to 0x102FFF).
  3. Boot check the whole new app data and match the checksum.
  4. Boot jump to app. At this moment, the whole firmware doesn't work...

I debugged and found it reports the PIE Vector Error:

So I debugged as follows:

  1. Use "DINT;" disable all the interrupt before jumping to the app.
  2. Disable all the interrupts in boot. Do not initial any interrupt at the firmware.

However, this error doesn't resolved. 

Please support me with this problem. I can accept a new way for writting the boot. Please let me know. Thank you!

  • If I mask these two lines, the whole boot didn't report this error anymore.

     

    Fullscreen
    1
    2
    3
    // jump to addr
    // __asm(" MOVL XAR7, #0x87000");
    // __asm(" LB *XAR7");
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    So, what command should be used to jump from boot to app in TMS320F28P650DH?

  • I apologize for the delay. I am going to loop in the bootloader expert to see if they have any input on this. That ESTOP is usually hit when an interrupt that has been enabled in the ePIE but doesn't have an associated ISR is triggered. Are you enabling/using any interrupts in your bootloader? Even though you are calling DINT, it could be that an interrupt from before that is already being propagated through.