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

TMS320F28379D: Cold Temperature C2000 Stuck In Boot ROM

Nigel Paine
Intellectual 310 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

During one of our thermal chamber tests, we ran our production software on our custom PCB with the C2000 chip installed (externally clocked 200 MHz). The code runs as expected all the way down to -40C. Upon reaching -40C we power cycle and the code doesn't run anymore. I believe the F28379D chip is getting stuck in boot ROM since there are other LEDs on the board that light up indicating that power is ON but not toggling (indicating that the code has not completed boot/initialization and is not running). Note that after doing a CPU reset and restart from the debugger, the code runs once again at -40C. The same behavior was observed with 2 separate copies of the same custom PCB and 2 versions of existing code (one is single core source code and the other is dual core source code, both have been verified to be working at room temperature). Is there any reason why the F28379D chip would have difficulty booting from FLASH by itself at -40C (as the datasheet says it is rated for)?

We don't believe it's a clock issue since the code runs normally all the way down to -40C. Thoughts?

EDIT: I was able to connect to the frozen target (no pun intended) and load boot ROM symbols from the following .out file:

"C:\ti\c2000\C2000Ware_3_03_00_00\libraries\boot_rom\f2837xd\revB\rom_sources\ccs_files\cpu01\Release\F2837x_cpu01_bootROM_REVB_Golden_020314.out"

and then point it to the following source folder path so i could step through code where it's hanging up:

"C:\ti\c2000\C2000Ware_3_03_00_00\libraries\boot_rom\f2837xd\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source"

I found out that it was hanging up at the line "while(WAIT_HOST_ACK)" in Parallel_Boot.c

Perhaps this could give a hint as to why it isn't running at -40C? Also please note that our boot pins GPIO72 and GPIO84 are currently floating (not-connected) so perhaps that explains why we are booting into parallel IO boot mode (which I don't think we want), perhaps adding pullups to the boot pins would resolve this issue so we can select boot mode Get/Flash instead?

  • 0
    TI__Guru 62975 points

    Nigel,

    Is my understanding correct in that:

    1. The PCB does not run correctly at -40C when power cycling without a debug probe connected, but
    2. The PCB does run correctly at -40C when resetting and restarting using a debug probe

    I recommend checking these boot status registers after a failed power-cycle to see if there are any errors or if the wrong boot mode was detected:

    -Tommy

  • 0 in reply to tlee
    Intellectual 310 points

    Yes, that is correct.

    Ran some tests reading the CPU1 Boot ROM Status memory value (address: 0x0000002C) and the CPU1 Boot Mode Address memory value (address: 0x00000038), here were the results:

    1) Cool chamber to -40C, use CCS debugger to FLASH code:

    Before running main():
    CPU1 Boot ROM Status: 0x00000000
    CPU1 Boot Mode Address: 0x00000000

    After running main():
    CPU1 Boot ROM Status: 0x00000000
    CPU1 Boot Mode Address: 0x00000000

    Results: code runs normally 

    2) Power cycle at -40C:

    After re-connecting debugger (but not resuming):
    CPU1 Boot ROM Status: 0x00000000
    CPU1 Boot Mode Address: 0x00000000

    Resuming with debugger:
    CPU1 Boot ROM Status: 0x00000D00
    CPU1 Boot Mode Address: 0x00000000

    Results: stuck in parallel boot 

    3) Using debugger, reset CPU & restart at -40C:

    Before running main():
    CPU1 Boot ROM Status: 0x00000D00
    CPU1 Boot Mode Address: 0x00000000

    After running main():
    CPU1 Boot ROM Status: 0x00000D00
    CPU1 Boot Mode Address: 0x00000000

    Results: code runs normally 

    4) While debugger is connected, heat up from -40C to room temp 22C

    Before heating up to 22C:
    CPU1 Boot ROM Status: 0x00000D00
    CPU1 Boot Mode Address: 0x00000000

    After heating up to 22C:
    CPU1 Boot ROM Status: 0x00000D00
    CPU1 Boot Mode Address: 0x00000000

    Results: code runs normally 

    4) Power cycle at 22C:

    After re-connecting debugger (but not resuming):
    CPU1 Boot ROM Status: 0x00000000
    CPU1 Boot Mode Address: 0x00000000

    Resuming with debugger:
    CPU1 Boot ROM Status: 0x00000D00
    CPU1 Boot Mode Address: 0x00000000

    Results: code runs normally 

    Not sure if these values are correct since I don't know if something is overwriting these RAM values prior to main() or if the debugger is overwriting these values. Either way, we also ran a test with a launchpad XL (same chip) using demo blinky code and set the boot mode switches to parallel mode (GPIO84 = 0 and GPIO72 = 0) and it behaved exactly the same as our PCB at -40C with a power cycle (waiting for an ACK from parallel host device...which of course doesn't exist on either system so it gets stuck). When switching the boot mode switches back to get/flash mode (GPIO84 = 1 and GPIO72 = 1) the launchpad behaved as normal (blinking LEDs).

    So it seems that our PCB Is booting in parallel boot mode at -40C, and in get/flash mode at room temperature 22C. What we don't quite understand is why heating up/cooling down would cause the C2000 boot modes to switch. Perhaps it's simply because GPIO84 and GPIO72 are floating and require pull-up resistors to force a default of get/flash boot mode?

    Also, it seems that the debugger boots from its own mode or wait mode so that overrides the parallel mode when it is at -40C, thus allowing the code to run normally?

  • 0 in reply to Nigel Paine
    TI__Guru 62975 points

    Nigel Paine1 said:
    Not sure if these values are correct since I don't know if something is overwriting these RAM values prior to main() or if the debugger is overwriting these values.

    Correct, these values could potentially be overwritten by CPU activity.

    Nigel Paine1 said:
    Perhaps it's simply because GPIO84 and GPIO72 are floating and require pull-up resistors to force a default of get/flash boot mode?

    The boot selection pins require external biasing to select the desired boot mode.  There is no internal mechanism to intentionally bias their voltage levels at reset.

  • 0 in reply to tlee
    Intellectual 310 points

    We confirmed the issue is indeed the floating GPIO boot pins preventing the CCA from booting. It seems that at cold temperatures floating GPIO pins tend to have a state of 0 and at warm temperatures floating GPIO pins tend to have a state of 1. Here were the test results:

    • Cooling down to -30C we observed the boot pins (GPIO72 and GPIO84) having a state of 0 (indicating parallel boot mode)
    • Heating back up to -25C (PCB Temp reads -23.1C) and doing a power cycle, while code isn't running and viewing the GPIO data registers, we noticed some of the floating GPIOs toggling, indicating thermal noise is changing some of the GPIO states
    • Heating further to -22.5C (PCB Temp reads -19.8C) and doing a power cycle, the PCB was stuck in parallel boot mode but booted up ~5 seconds later, our theory is that we have the perfect conditions to allow GPIO70 (parallel boot host ACK pin) to toggle freely, allowing the PCB to get through parallel boot mode...the other theory is that both boot pins (GPIO72 and GPIO84) toggled high allowing the PCB to switch to boot from flash mode, but this seems less likely since the C2000 shouldn't be switching boot modes mid-boot
    • Heating to -5C (PCB Temp reads -2.5C) and doing a power cycle, the PCB seems to be booting normally with the boot pins (GPIO72 and GPIO84) having a state of 1 (indicating get/flash boot mode)

    We've updated our schematics to include pull-up resistors on the boot pins to force get/flash boot mode.