- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hi Team,
There's an issue from the customer need your help:
1.TMS320F28335 sometimes do not start working after power up, we take it as XINTF bug by now, handling WDT flag and WDT reset.
2.This program have been in use for many years and is used on multiple devices.
3.This has recently been observed on individual devices.
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.
From the latest errata sheet of 28335, a sentence has been added for watchdog reset, “Note that the code should sample the WDFLAG bit only after a delay of 8192 SYSCLKOUT cycles from the time reset is deasserted.”
The actual test is currently 8 ms and should meet this.
I wonder is this bug not 100% successful to modify XINTF using watchdog reset? Or is there some issues with the CPU?
Could you help check this case?
Thanks and Regards,
Ben
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.
