• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 322 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.

F29H850TU: Reset target on program load or resetart

Lori Heustess
Guru* 93800 points

Part Number: F29H850TU

Customer's inquery:

We would like to use the “Reset the target on program load or restart” option, but it does not work as expected:

  •  After programming the device’s flash, the chip does not run to main() as expected.
  • The default boot-selection GPIOs (GPIO72, GPIO84 we use F29H850TU9TZEX) are configured with pull-up resistors, indicating boot from flash.
  • In debug mode, when the “Reset the target on a program load or restart” checkbox is enabled in the debugger configuration:
  • The CPU never reaches the entry point of main().
  • The program counter (PC) loops in the address range 0x000014XX.
  • Inspecting memory at 0x10001000 shows that the program has been correctly downloaded.
  • Without selecting the “Reset the target on a program load or restart” option, the debug session behaves normally, and execution reaches main() as expected.
  • No error message in the console, just the device doesn't run to main() as expected.
  • 0
    TI__Guru** 117311 points

    Hi Lori, 

    I think this is expected. If you reset the CPU1 (C29) and not reset the HSM then HSM <-> C29x handshake gets broken hence CPU1 get stuck in ROM waiting for IPC handshake. We did some fix on Rev-B for HSM <-> CPU1 handshake and that might fix this issue on Rev B but I need to confirm that.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Mastermind 26146 points

    hi Vivek,

    do you mean it is a silicon bug? (i.e. is Rev B is the silicon version?)

    if so, the only chance would be to change the IC with the latest/correct one. correct?

    or will there be a SW workaround?

    being these the first boards/build, we don't need all functionalities, hence any non-HW workaround is more welcome (at least to progress, because this bug is slowing us down a lot at the moment...)

    thanks 

    Vincenzo

  • 0 in reply to Vincenzo Pizzolante
    TI__Guru** 117311 points

    It was part of ROM code and was not a bug but we update the ROM code on new Silicon to make the user experience better.  

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Mastermind 26146 points

    hi Vivek,

    thanks, got it now.

    So if we reset the HSM too, we should fix this. Correct?

    May you guide me a bit in how to make it, in case?

    Vincenzo

  • 0 in reply to Vincenzo Pizzolante
    TI__Guru** 117311 points

    Yes, and one one way to do it just issue an XRSn (external or via CCS script like below)

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 10 points

    Hi Vivek,

    thanks for the answer, I tried the Scripts->CPU Reset Handling->Device_Reset_XRSn. It doesn't helps. The CPU1's PC will back to 0x00000000 then loop in range (0x00014258, 0x00014260). On our board, we also has a RC power reset circuit, where XRSn is pulled up with a 10K resistor, and pulled down with a 0.1uF capacitor. 

    What actually helps is when the CPU1 loops in 0x00014260, I click Scripts->Emulation Boot Mode Select->Enable_Flash_Emulation_Mode. Then stop the debug (click the red button) and restart the debug (click the green rightwards arrow) the CPU1 can stop at the entrance of main() and successive debug can proceed.

    However, when I power off the board, remove the JTAG cable from the board and power up the board again, it seems the CPU1 doesn't run to the application program, the LED on our board doesn't blink. We also wish the board can operate stand alone without the debuger.

    This is a more detailed follow ups of the issue we encounter, do you have any ideas about what cause the issue? thank you for your reply.

    Regards,

    Fangming

  • 0 in reply to Fangming Yuan
    TI__Guru** 117311 points

    Hi Fangming,

    Fangming Yuan said:
    However, when I power off the board, remove the JTAG cable from the board and power up the board again, it seems the CPU1 doesn't run to the application program, the LED on our board doesn't blink.

    If device is not booting in standalone then it could be some other issue. You may want to check if device is getting into some error status when connected with debugger and CPU get stuck in loop in range (0x00014258, 0x00014260).

    You can refer this appnote for the error condition debug - https://www.ti.com/lit/sdaa104

    Vivek Singh