TMS320F28335: sometimes do not start working after power up

Currently, the test found that it did not always come out, sometimes after a period of time. Sometimes it come out after power up and down a number of times (long intervals) 

Ben Qin said:

1.TMS320F28335 sometimes do not start working after power up, we take it as XINTF bug by now, handling WDT flag and WDT reset.

Is the boot-mode set to XINTF or does the application merely access the XINTF after booting?

Ben Qin said:

2.This program have been in use for many years and is used on multiple devices.

For how many years has this been in production? By "multiple devices", are you referring to multiple designs or numerous devices in the same end-product?

Ben Qin said:

3.This has recently been observed on individual devices.

Are these devices that were working fine for a long time but showing this issue recently?

Ben Qin said:

4.Tests have found that the watchdog reset signal is not present when not in operation and the program runs to the XINTF access and fails. Normally, there will be a watchdog reset signal of about 20us around 8ms after the reset signal is pulled high.

Are you saying that even though customer implemented the workaround, the WD-initiated reset is not seen after power-up? 

Ben Qin said:

The actual test is currently 8 ms and should meet this. 

Assuming SYSCLKOUT is 150 MHz, 8192 cycles equates to 54.6 uS. Are you saying code is sampling the WDFLAG bit 8 ms after reset?

Ben Qin said:

I wonder is this bug not 100% successful to modify XINTF using watchdog reset? Or is there some issues with the CPU? 

We have not heard of any issue after the workaround has been properly implemented.

Ben Qin said:

Currently, the test found that it did not always come out, sometimes after a period of time. Sometimes it come out after power up and down a number of times (long intervals) 

Sorry, this is not clear. "Come out" of what? Reset? Do you have any power-up waveforms that you can share? I would like to see 3.3v and -XRS pin.

Hi Hareesh,

Thanks for your reply.

Hareesh Janakiraman said:

Is the boot-mode set to XINTF or does the application merely access the XINTF after booting?

Is not boot-mode, we configure it direct to flash.

Hareesh Janakiraman said:

For how many years has this been in production? By "multiple devices", are you referring to multiple designs or numerous devices in the same end-product?

Around 8 years. Same end-product.

Hareesh Janakiraman said:

Are these devices that were working fine for a long time but showing this issue recently?

Yes.

Hareesh Janakiraman said:

Are you saying that even though customer implemented the workaround, the WD-initiated reset is not seen after power-up? 

Yes.

Hareesh Janakiraman said:

Assuming SYSCLKOUT is 150 MHz, 8192 cycles equates to 54.6 uS. Are you saying code is sampling the WDFLAG bit 8 ms after reset?

Yes.

Hareesh Janakiraman said:

We have not heard of any issue after the workaround has been properly implemented.

After we power up, the reset signal is normal, about 250ms after the reset signal turns high, now the CPU doesn't working. A IO instruction was added to program, it is before access XINT address, and it didn't show up.

Hareesh Janakiraman said:

I would like to see 3.3v and -XRS pin.

The time between 3.3V power up and reset signal turn high is about 250ms. It seems normal. We tested boot state in start up, all 4 is high. No other abnormalities have been found for the time being, and we plan to replace the CPU and test again.

Thanks & Regards,

Ben

Ben Qin said:

After we power up, the reset signal is normal, about 250ms after the reset signal turns high, now the CPU doesn't working. A IO instruction was added to program, it is before access XINT address, and it didn't show up.

This is an important clue. By "IO instruction", I presume you are referring to a toggle of a GPIO pin. If code prior to XINTF access does not execute properly, the issue is not related to the XINTF bug.

Ben Qin said:

The time between 3.3V power up and reset signal turn high is about 250ms. It seems normal. We tested boot state in start up, all 4 is high. No other abnormalities have been found for the time being, and we plan to replace the CPU and test again.

I still request you to send me the power-up and power-down waveforms. I'd like to see 1.8v, 3.3v, -XRS and the input clock.

Hi Hareesh,

Now we confirmed that the problem have nothing to do with XINTF bug.

We suspected that it has entered certain boot mode, but currently the pull-ups of the 4 boot mode pins are normal.

When reset signal turns high, the CPU has no further action, Because the reset uses the TPS3307, the signal going high means both 1.8 and 3.3V are OK.

At the same time, the clock signal is also tested when the power is turned on, and it is also normal.

That is, after power-on, the clock signal is normal until the reset signal becomes high, and then the CPU has no further action.

Is it possible that CPU damaged by static electricity? 

Thanks & Regards,

Ben

Are you able to connect to the device via CCS? If so, download the flash contents and compare it with the "golden image" to ensure that the flash memory contents are not corrupted.

It appears TPS3307 has a push-pull output. We only recommend open-collector devices to drive our -XRS pin. This is because our reset pin is both an input and an output.

Ben Qin said:

Is it possible that CPU damaged by static electricity? 

Possible, but I wonder how you are seeing this problem suddenly after 8 years of normal operation.

I once again request both power-up and power-down waveforms. I want to see 1.8v, 3.3v, -XRS and CLKOUT signals.

Ben,

      Is this post related to https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1194713/tms320f28335-28335-program-does-not-work/4504994#4504994? 

• Yes, it's the same question，These boards were recently produced and replaced on the equipment for about 1 month. They worked well until the occasional failure. We suspect that the replacement process is damaged, but we have done so before. I haven't seen such a problem

jh chen said:

Yes, it's the same question，

Please do not open duplicate posts to discuss the same issue. It makes the debug process inefficient. I will close the other post. Let us use only this post moving forward.

Chen

I have sent you a friendship request. Please accept it. Once you do that, you can send me the schematics privately to me, without posting it on the forum. I need the PDF file, not the screenshot. As mentioned before, you don't have to send me the entire schematics but I definitely want to see the connections to every pin of the DSP.

Hi Hareesh,

I have sent it to you, please check the message

Thanks & Regards

I have received it. I will take a look and get back to you.

We've been using this design for years. Recently it was just a redesign of the PCB. Then replace it with a device to use. About 1 month later, there was a situation that it did not work during power-on. For the faulty board, we can reproduce the fault by repeatedly powering on the board. After we removed the DSP from the fault board card and replaced the DSP, the fault was no longer repeated in the test. After replacing the faulty DSP with another board, the fault can still be rectified. Therefore, we locate the DSP fault. But it's not clear what caused the malfunction. 

We have used this DSP a lot and have never seen this kind of fault before. Welding and inspection are normal。Whether the DSP is damaged due to improper protection during the replacement of the board card. Is there any precedent for this?

I looked at the schematics. Evidently, you have not sent the complete schematics since I couldn’t see the JTAG & XINTF connections. Anyway, the only issue I saw was that the -XRS pin was being driven by TPS3307, which does not have an open-drain output (based on its datasheet). Our datasheet says “The output buffer of this pin is an open drain with an internal pullup. If this pin is driven by an external device, it should be done using an open-drain device.” Please consider fixing this in your next design cycle. In any case, I doubt if this is the root-cause of the issue you are seeing right now. You mentioned after replacing the faulty DSP, the board started working again. If you mount the faulty DSP on a known-good board, does that board stop working? If so, that would conclusively prove that the fault lies with the DSP itself and not with the board. I presume that is what you are saying with " After replacing the faulty DSP with another board, the fault can still be rectified". Interestingly, the board works fine for a month before showing this problem. There is always a possibility that the device has been damaged due to ESD or other improper handling, but how did it work fine for a month? You have not answered my below question from an earlier post. Please answer it:

Are you able to connect to the device via CCS? If so, download the flash contents and compare it with the "golden image" to ensure that the flash memory contents are not corrupted.

One area to check is whether proper power-supply sequencing is followed for both power-up and power down. This is the reason I have been asking for the waveforms. The scope capture should clearly show 1.9v, 3.3v and -XRS clearly in the same screen. See attached image for a sample.

hi，we have a mistake. It's JTAG that has a problem here.

This is being dealt with offline.