• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 463 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.

TMS320F280041C: Debugging operation with F280041 and XDS110 is different than running stand alone

Bruce Nielsen
Prodigy 210 points

Part Number: TMS320F280041C

Tool/software:

Hello,

We've encountered an issue where our stand alone firmware fails under a specific condition but when this same code (the code is not rebuilt when initiating debug) is run with the XDS110 it runs fine.  I'm trying to understand what the differences are between standalone and debug operation and wondered if there was a document that covered the differences.

The problem we are seeing is our bootloader will successfully load an application the first time using either stand alone or debug operation of the bootloader.  You can restart the controller and in both cases the bootloader will now find a valid application and jump to it.  But if after the first successful download we restart a new download (no repower just tell the tool communicating with the TI target to start another bootload) the system with debug attached will successfully start and complete (and you can do this repeatedly).  But, the standalone board will fail on the 2nd bootload attempt.

Thanks for any help you can provide.

Bruce

  • 0
    TI__Mastermind 20380 points

    Hi Bruce,

    Bruce Nielsen said:
    I'm trying to understand what the differences are between standalone and debug operation and wondered if there was a document that covered the differences.

    I recommend you start by referencing the boot flow diagrams for standalone and emulation boot in the TRM (Section 5.5 Device Boot Flow Diagrams) to understand the differences. There are a lot of details included in the Boot ROM chapter. 

    I have a couple of questions about the issue:

    1. Can you show what boot configuration you programmed into the OTP for standalone and in RAM (0xD00) for emulation?
      1. What boot mode select pins and boot definitions are you selecting?
      1. Does the device jump to the new application before restarting the download or does this happen while it's still in the bootloader?

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 210 points

    Matt,

    I don't modify the boot configuration in OTP normally for a prototype.  For production we modify GPREG1, GPREG3, and BOOTCTRL to force the bootloader to boot from FLASH.  I do nothing during debug with 0xD00.  My debugging is done using a FLASH build and the two pins that determine bootmode are configured for FLASH boot.

    The bootloader is J1939 CAN based.  When a boot cycle is finished the bootloader stays active.  We can tell the bootloader to jump to application but we are not doing that in this cycle.  We run a bootload as commanded via CAN and then when the first cycle finishes successfully we rerun this same cycle by sending the same CAN commands.  If I'm running in JTAG the process appears to run successfully but if I run standalone when I command a FLASH erase the bootloader hangs.  Its this difference that I'm trying to understand.

    One interesting point that we discovered is that with both JTAG and non-JTAG operation of the bootloader after the 2nd attempt both fail to properly program the flash as when we power down and power up with JTAG removed (if needed) the program stays in boot as it deems the application invalid which normally occurs because the CRC stored in EEPROM doesn't match CRC calculated on application flash.

    Thanks - Bruce

  • 0 in reply to Bruce Nielsen
    TI__Mastermind 20380 points

    Hi Bruce,

    Thank you for the clarification, I'm going to loop in the Flash API expert to assist.

    In the meantime, I have a couple extra questions:

    Is the Flash API being copied into RAM along with .TI.ramfunc? Can you share your linker command file and .map file (found in the build config folder) for the bootloader? Also, how do you initialize the Flash API in the bootloader?

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 210 points

    Matt,

    So we got the standalone version working so that if you ran multiple programming cycles while staying in the bootloader it would work.  It turned out to be a pointer issue.

    The issue I described in the last paragraph of my last response has also been addressed.  It was due to an improper flag being sent via CAN.  This has also been addressed.

    What I'm still confused by is what the same code in standalone would lock up while this same code under JTAG debug would run repeatedly and once we fixed the CAN flag problem the JTAG version would work as expected while the standalone locked up during the 2nd programming operation.  It made troubleshooting this problem difficult since you couldn't debug via JTAG to catch the issue.  I thought it might be some of the error trapping but these routines used ESTOP0 so during debug I shouldn't have hit these and during run mode I should have hit the infinite loop that sat after the ESTOP0.

    Thanks - Bruce

  • 0 in reply to Bruce Nielsen
    TI__Mastermind 20380 points

    Hi Bruce, 

    Thank you for updating the thread with a resolution! It is unusual that JTAG debugging wasn't able to catch the issue, I will investigate this and update this thread if a reason is discovered. 

    Best,
    Matt