• 状态 TI Thinks Resolved
  • 回复 3 回复
  • 答案 2 答案
  • 订户 29 订户
  • 视图 99 视图
  • 用户 0 会员在此处
选项
选项
相关

TMS320F28388D：boot failure

y z
Prodigy 10 points
Part Number: TMS320F28388D

Hello, currently there is a problem. When in the Flash/USB BOOT boot mode, after the chip is powered on, without any external control, the chip frequently resets, resulting in the program being unable to continue running. After reprogramming the faulty board with the same program, the malfunction disappeared. When the program of the faulty board card was copied to other identical board cards, the fault could not be reproduced. Currently, it is suspected that there were certain issues during the period from the BOOT-RAM stage to the user program stage that led to this failure. Could you please explain how to conduct the fault investigation in this situation?
The following is the output state of the reset pin on the chip after it is powered on.

  • 0
    TI__Mastermind 38080 points

    Thanks for your patience. To clarify, have you been able to reproduce the issue at all since you saw it? It is difficult to debug when the issue is not actively reproducible. 

    One typical flow I recommend is using emulation boot mode. If the issue occurs when the device is booting standalone to Flash, you can use emulation boot mode to debug/step through the emulated standalone boot flow while remaining connected to the device. Is this something you've already done?

    The periodic resets are due to the watchdog being active. Are you referring to the error in regard to the period in which there are no resets occurring in the waveform image? Some more context there would be helpful for my understanding of when these waveforms were captured. 

  • 0 回复 Vivian Gao
    Prodigy 10 points

    First of all, I would like to thank you for your reply. At present, the fault where the watchdog is constantly activated can be reproduced. The specific operation is to use the debugging tool to burn in the program that you have edited. Run it normally. After the program runs, click the "reset" button in the CCS debugging interface. At this point, measuring the reset pin can reproduce the fault.
    However, this fault phenomenon is different from the situation of the two faulty chips. Currently, it has been found that there are two chips with this fault. Before performing the above operation, reprogram one of the chips with the same code once, and the fault is eliminated. After reproducing the fault through the above operation, the fault will also be eliminated when the power is re-applied. The other faulty chip was not reprogrammed for comparison purposes, but even after re-powering, the fault could not be eliminated for this chip.
    I would like to ask if there is any kind of fault detection mechanism inside the chip, such as a fault register or a fault status signal. When the chip is powered on and runs before the program starts, detecting this register or status signal will automatically activate the watchdog, preventing the program I compiled from starting normally.

  • 0 回复 y z
    TI__Mastermind 38080 points

    The F28388D has several fault detection mechanisms. For example:

    • Watchdog timer (WD)
    • NMI (Non-Maskable Interrupt) system
    • ERRORSTS pin (Error Status) that indicates various fault conditions
    • Flash ECC error detection
    • Reset cause registers that can be checked to determine the source of resets

    The behavior you're describing where the watchdog is constantly activated could be caused by several mechanisms, e.g.:

    1. ITRAP/Illegal Operation Detection:
      1. When an illegal operation or ITRAP occurs, the Boot-ROM ISR enables the watchdog automatically
      2. This can happen if program memory is corrupted or if the program counter gets corrupted due to noise or other issues
    2. Flash ECC Errors:
      1. The device has Flash ECC error detection that can trigger NMI and potentially cause watchdog activation
      2. You can check the NMISHFLG (NMI Shadow Flag Register) to see if there are any Flash uncorrectable errors
    3. Reset Cause Detection:
      1. You can check the RESC (Reset Cause) register to determine what triggered the reset
      2. The WDRST (Watchdog Reset) bit in RESC will indicate if the watchdog was the cause
      3. The register needs to be cleared manually or by POR (Power-On Reset)

    Recommendations for Debugging:

    I would try the below and compare between working and non-working chips:

    1. Check the RESC register immediately after power-up to determine the reset cause 
    2. Monitor the ERRORSTS pin status, as it can indicate various fault conditions (just keep in mind, ERRORSTS can be triggered by several different sources)
    3. Examine the NMISHDFLG register for any Flash ECC or other errors
    4. Try running the code from RAM instead of Flash to determine if the issue is Flash-related
    5. For the chip that continues to have issues even after power cycling, try emulation boot and see if you see the same issue or can debug.