TMS320F28388D: About the ERRORSTS and XRSn pins status when power on

Hi,

Can you also scope your power signals? Why is XRSn taking 13.8ms to ramp? What are you connecting on your board to XRSn?

Also, I am not clear on your power sequence. Can you please elaborate what is the power sequencing here?

Thanks & Regards,

Nirav

Hello Nirav

thank you for your reply.

please check the following pics for the power rail test and schematic.

the yellow one is 3V3 and the blue one is 1V2.

We checked the power on sequence, this should be OK.

(please ignore the spike at the beginning.)

Hi,

Thanks for the waveforms, but can you capture supply and XRSn in the same plot, I would like to see if there are any glitches in the supply even if it is in few 100mV it will cause XRSn to assert.?

Best Regards,

Nirav

Hello Nirav,

I will upload later.

the 1.2V rail do have glitches, I remembered that less than 100mV.

the 3.3V rail does not have obvious glitches.

The 13ms is an indicator of a loop in the watchdog reset.  With some boards showing the issue and other boards okay, I would check for possible soldering issues.  Is this a PCB in development, or one in production for a long time?

Specifically you can check the Boot Pins to ensure they are as intended and you are entering the correct boot mode.  Also if booting to Flash, check that the flash was programmed with the expected program on this board.

Hi Nirav,

Sorry for the late reply. it took us some time to make the board show the failure again.

CH2, light blue, reset pin

CH6, dark blue, GPIO121 output

R1 saved reference, 1.2V power rail

R3 saved reference, 3.3V power rail

The Power rails are OK, no spikes. But some of the GPIOS, including some EPWM output have this low frequency output. 

additional information

1, MCU reset and ERRORSTS and JTAG sch.

2, the soldering is OK from the analysis of the manufacture. I will share the X-RAY pictures later when I get them 

Thank you for your replay and suggestion.

This is a PCB in development, just finished V3 design but not produced due to this failure. The failure ones are all belong to V2.   5 pcs V1 are all OK.

For the boot mode, both versions are with default mode Flash/usb. 

Thanks for the update.  Since it appears the watchdog is causing the reset, can you check that the software always services the watchdog without a chance for code interrupt which would prevent it being serviced.  Also that you have an NMI watchdog ISR defined.

Hello Jason,

some update from software engineer,

1, watchdog has been disabled;

2, seems like the software is not running, we can not get CAN data from MCU.

Hi,

Are you supplying clock externally, meaning using XTAL or INTOSC?

Best Regards,

Nirav

We are now using XTAL, 25M,

The clock signal looks OK.

Hi,

Are you able to connect to CCS on this device ? If you have not tried this then please try to connect to CCS and see if that stops the toggle and XRSn and then you can look at NMISHDFLG register in CCS register view and let us know what value you see. Also check the value at address 0x2 (BOOT STATUS) in CCS memory watch window and let us know. 

Regards,

Vivek Singh

Hello Vivek

sorry for the late replay.

feedbacks from control engineer--

the following picture shows the program stopped position when the error took place. But the stopped position not always here.

the stopped position always at the initial of the MCU,  some times we can pass these a few line C , then the MCU will be OK.

NMISHDFLG is 1 when the error shows up.

here is the the value at address 0x2 (BOOT STATUS)

Thanks !

BR

LYZ

Hi,

user5988235 said:

here is the the value at address 0x2 (BOOT STATUS)

This look good. There is no error signature in this status. Program stops in ROM CODE because of wait boot.

Regards,

Vivek Singh