• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 82 subscribers
  • Views 1129 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28069: Copied code using secondary bootloader; now getting stuck in an ISR

Parag Shah
Intellectual 280 points

Part Number: TMS320F28069

I have a project (call it main) created that copies the contents of another project's hex file (call it blinky) into the FLASH areas not in use by project main.

I am using the Flash_Program() and Flash_Verify() routines to verify that the code copied into the FLASH regions is correct. 

The final step after the _Program/Verify routines in main is to jump to the code that will start the blinky project. I added the call     asm(" LB 0x3EFFFE"); which has the call to basically run the rest of the code that is copied to FLASHC. The way I know this is that when I was debugging blinky the .cmd file has BEGIN associated with the address 0x3EFFFE and I look at the contents of that address and the same data is copied by main.

When I execute this asm call, I get stuck in the ESTOP associated with USER11_ISR. 

//
// USER11_ISR - User Defined trap 11
//
__interrupt void
USER11_ISR(void)
{
//
// Insert ISR Code here
//

//
// Next two lines for debug only to halt the processor here
// Remove after inserting ISR Code
//
__asm (" ESTOP0");
for(;;);
}

What am I doing wrong?

  • 0
    Prodigy 100 points

    Parag, 

    Can you post the disassembly to see if there's not a trap 11 or some other  branch to that location being called?  I don't think is an illegal instruction or else it would have been a trap 19 ISR. 

    Also, read the bottom of this post: 

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/383198/1357443#pi316717=4

    Which states that a Trap is asserted when 0xFFFF is data in the memory location.  Thus, you may need to change the address where the main application starts for example, asm(" LB 0x3EC000"); for Flash C. 

  • 0 in reply to Matthew Dolton54
    TI__Guru 55700 points
    Shah,

    Please try Matthew's suggestion. Alos, did you already check jumping to 0x3EFFFE and single stepped through the code to understand why it branches to USER TRAP ISR? This is the only way to debug the issue.

    Regards,
    Manoj
  • 0 in reply to Matthew Dolton54
    Intellectual 280 points

    Here's the disassembly:


    So it's clear that there is something wrong with the code that it is executing. 

    I went back and looked at the hex file that I was copying, and interesting when I compare the code in the FLASHC location from the workspace_v7 (which has the image loaded directly through a JTAG), I see the values in the disassembly as follows:

    So, it appears, the code didn't get copied correctly. The Flash_Program() takes in a Uint16*. The output of the hex file is a 8-bit characters. Can I get the hex to output a 16-bit word? Clearly, me mashing the two 8-bit words together was done incorrectly.

  • 0 in reply to Parag Shah
    TI__Guru 55700 points
    Parag,

    Didn't we already talk about getting the hex data in this thread? e2e.ti.com/.../2609253

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 280 points

    Manoj, we did discuss this in the other thread. 

    I followed your instructions (less taking the contents of the memory from the main application and input them as a buffer into the bootloader). The implementation is going to be to take a compiled .hex file and use that as a source. My attempts were to do exactly that; take the ASCII output of the hex file and then import that as an array into the bootloader code to program the processor. 

    Using Flash_Program() requires a Uint16 * as a parameter, and the data output from the Hex Utility is in 8-bit characters. I tried mashing the values together to create my own 16-bit array, but the resulting opcodes do not equate to the same when viewing the disassembly.

  • 0 in reply to Parag Shah
    Intellectual 280 points

    Manoj, I did the memory output and tried copying it into the flash using flash_program...same result. For some reason, the 8-bit output doesn't convert to the correct opcode that the processor expects.

    When I did the memory dump in 16-bit format, the copy worked as expected, and I was able to jump into the new code (interestingly, the first thing it does is hit another ISR)

    Here's the flow.

    1) FLASHC is blank before the copy begins

    2) Code calls the Flash_Erase (even though nothing will really happen, since the FLASHC region is already cleared)

    3) Calling the code to Flash_Program() and Flash_Verify() the data that is copied to 0x3e0000

    4) Showing that the data is properly copied to 0x3e0000

    5) About to copy the data to 0x3ec000

    6) Showing that the new code does truly exist at 0x3ec000

    7) About to jump to 0x3ec000 and start executing the new code

    Doing this runs immediately into an ILLEGAL_ISR

    I'm getting frustrated. Either I'm doing something so basically wrong, or I'm missing a step that I have not read about. PLEASE HELP!

  • 0 in reply to Parag Shah
    TI__Guru 55700 points
    Parag,

    Value programmed in address 0x3EC000 = 0xFFFE is not a valid opcode. When executing 0xFFFE CPU realizes that it isn't a valid opcode and jump to ILLEGAL_ISR().

    I don't know how you have configured your application code. Assuming you tested your application code to be working when you programmed using CCS plugin. I would assume that you have got your jump address wrong. When you want to jump to your newly programmed code you need to jump to address of the 1st opcode you need to run. What is the BEGIN address of the hex code you are programming using Flash API? What does .cmd file say?

    Regards,
    Manoj
  • 0 in reply to Manoj Santha Mohan
    Intellectual 280 points
    Manoj, you are correct. In my attempts to debug, I did change the asm call to 0x3eC000 and forgot to change it back to what BEGIN was using. THE CODE IS WORKING NOW AS EXPECTED!
    Thank you for your guidance and feedback.