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.

TMS320F28388D: Frequent automatic resets occur after power-on startup

Part Number: TMS320F28388D

Hi Teams,

The customer's application is a fault diagnosis system for rail transit,mainly for subway applications.

During daily operation, two cases of abnormal vibration signal data were reported by on-site vehicles. After further investigation, it was found that both cases were caused by abnormal startup of the main control DSP, resulting in the loss of vibration data. The related boards with abnormal DSP startup cannot be eliminated or restored to normal through power outage, reset, and other situations.
1) The composition of the faulty vehicles is as follows: each train has four main engines, totaling 8 running boards.
2) The failure rate is approximately 12.5%
3) Fault card status: Returned for fault location analysis.

After the faulty board was returned, preliminary positioning revealed that the two fault phenomena were completely consistent.
The specific fault information and symptoms are as follows:
1)The model of the DSP main control chip is F28388DZWTS;
2)After the board is powered on, the chip frequently undergoes automatic reset, causing the program to fail to run normally. Measure the XRSn pin of the DSP chip, and the detailed signal waveform is shown in the following figure

image.png

Figure 2 DSP XRSn signal waveform diagram

image.png

3) After forcibly lowering the XRSn pin of the DSP chip, the board still cannot start and the fault has not disappeared. The waveform after measuring and lowering the XRSn signal is shown in the following figure:

image.png

4) Connect the simulator to read the program from the DSP on the faulty board A, rewrite the read program to the faulty board A, and power it on again. The DSP can start normally, the fault disappears, and all testing functions are normal. At this point, the XRSn pin is measured and the pulse reset signal disappears.
5) Connect the simulator to the faulty board B and use the debugging function. After the chip is started, it cannot enter the program that has been programmed and solidified. At this time, the status of the registers is as follows:

image.png

6.By analyzing the registers,it was found that both FLUNCERR and RAMUNCERR are 1, causing the board to continuously trigger NMI and reset. Further examination of the status of the PREFETChEN register revealed that it has been disabled, and upon checking the UNC-ERROADDR-HIGH register, it was found that the address is 0.

image.pngimage.png

7)Due to the disappearance of the fault after program re burning, it is not currently considered a hardware malfunction.However,due to the continuous automatic reset of the DSP chip of the faulty board, the program cannot be started and software positioning cannot be performed, making it difficult to analyze the fault.

read_ok.zip 

The attachment contains some files read by the customer,
Read_error.bin: The file read from the board that cannot be started
Read_ok.bin:The file read from the normally started board
Boot.bin: The file generated by CCS compilation

Please help me take a look at this issue,thank you!

  • Hi,

    Can you confirm the NMISHDFLG reading for all boards that are failing ?

    Can you modify your NMIISR to clear the flags and put a while loop in the NMI ISR so that the NMIWD doesnt timeout and its possible to debug the rootcause of the NMI trigger.

    Thanks

  • Hi Prathan,

    Regarding the operation of adding a while loop, the customer will conduct a test. Thank you for your guidance

  • Hi Prarthan,

    Customer feedback: Due to previous incidents where the board returned to normal after programming, there is still a faulty board. In order to prevent fault recovery after programming, there is no available debugging board. Are there any other debugging methods that do not require programming?

  • We would need to know the root cause of the error for debugging, at this point seems like we dont know what the cause of NMi is on both boards.

    Thanks

  • Hi Prathan,

    The problem now is that the client's program cannot enter the program they wrote themselves, and it feels like it has been restarting continuously after an error occurred while loading the program from Flash during boot. (Similar to the phenomenon when there is no program in Flash).

    28388 supports SCI and USB booting. Is there any relevant information on this? If this problem cannot be solved, they want to try changing the strategy.

  • Hi,

    Cannot understand what the issue  is here.

    Is user able to program the code and enter NMI ? Are they able to see the error they saw before ?

    28388 supports SCI and USB booting. Is there any relevant information on this?

    They can refer to device reference manual - Boot rom chapter for more info on this. Can you create another e2e for the bootloader issue, when you are able to reproduce the NMI issue we can continue to discuss on this thread.

    Thanks