• 状态 TI Thinks Resolved
  • 回复 11 回复
  • 答案 5 答案
  • 订户 29 订户
  • 视图 339 视图
  • 用户 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 38780 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 38780 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.
  • 0 回复 Vivian Gao
    Prodigy 10 points

    Thank you for your reply. Based on the ideas you provided, when checking the registers of the faulty board card, it was found that FLUNCERR and RAMUNCERR were both 1. The board card continuously triggered NMI, causing it to keep resetting. Could you please list the specific items that need to be tested in order to determine the causes of this malfunction?

  • 0 回复 y z
    TI__Mastermind 38780 points

    Thank you for providing the status of the registers shown. To further debug, could you please try disabling ECC through the following register on the unit that you are re-programming and see if you still observe the issue?

    Could you please also let me know the status of the FRD_INTF_CTRL  register? I would like to check if pre-fetch has been enabled. If it has, then please also test to see if disabling pre-fetch also removes the issue.

  • 0 回复 Vivian Gao
    Prodigy 10 points

    Hello, thank you for your reply. I used the debugger to debug the faulty chip and checked the following register states. I'm not sure if this is what you need. If it is not this register, please let me know which register is the correct one. If so, please let me know which additional data needs to be investigated.

  • 0 回复 y z
    TI__Mastermind 38780 points

    Thank you for checking. The register view shows that Prefetch has been disabled (PREFETCH_EN).

    Were you able to check if you have ECC enabled or not?

    I'd also like to view the ECC Error Address. There are two registers that capture this information in the Flash_ECC_Regs Registers

    If the error address points to a non-flash based address then please note this FAQ:  [FAQ] TMS320F28388D: [FAQ] Why does the CM core on the F2838xD device sometimes gets into an NMI exception, reporting an uncorrectable flash ECC error that points to a non-flash address at runtime?

  • 0 回复 Vivian Gao
    Prodigy 10 points

    Thank you for your reply. However, the image in your response cannot be loaded. Could you please resend this image so that I can better confirm the required data?

  • 0 回复 Vivian Gao
    Prodigy 10 points

    Hello, in the previous register screenshot, you can find the exact register value you need. This screenshot was taken after the board was powered on and was in an abnormal reset state. It was viewed using the "Load symbols only" option for debugging. It's just that the value of this register is 0.

  • 0 回复 y z
    TI__Mastermind 38780 points

    Thank you for providing the clarity. When the programs enters the triggered NMI's ISR. Can you please do another read of the PREFETCH_EN, ECC_ENABLE registers and of the UNC_ERR_ADDR_LOW/HIGH registers. I'd like to see what address the uncorrectable error is pointing to when the NMI is triggered. Looking at the screenshot above the address values are still 0.