F28M36H33B2: Concerto C28 reset on startup

So, there is no issue running code off M3 flash and C28 RAM, but you see this issue only when you attempt to run from C28 flash? It appears the watchdog may be timing out but you have confirmed absolutely nothing has changed in your board  and software. 

Please answer the following questions: 

1. How long has this design been in production?
2. In how many boards is this problem seen? Does every board in the new batch exhibit this failure?
3. In a board where the problem is seen, is the problem intermittent or permanent?
4. If the problem is intermittent, how often is it seen?
5. Is it possible to reproduce the problem easily?
6. Is this seen in a device that has been working fine for some time? If so, how long?
7. Does the code work fine with the JTAG connector connected? 
8. Is it possible to reproduce the problem with CCS-JTAG connected?
9. Does it make a difference to run the code from Flash as opposed to RAM? From your post, it appears there is.
10. Are the levels of the boot-mode pins correct while the device is coming out of reset (and when the boot-ROM takes a snapshot of those pins)?
11. Is there any temperature dependency to the issue? i.e. does the rate of problem occurrence vary based on the ambient temperature?
12. Can you try the most recent CCS version ? 

The link you provided does not work.

Hi Hareesh

The problem occurs when running from flash or from RAM. It does however seem that the problem initially occurs on the C28, because if I start he cores one by one via CCS (loading into RAM) the M3 runs fine, until the C28 starts.

1.How long has this design been in production?

From version A we have been using it for a few years. Of the latest version C, we built 14 boards which worked fine. Then the next batch of version C was built where I started to see the problem. 

2.In how many boards is this problem seen? Does every board in the new batch exhibit this failure?

On this batch 4 boards has been fully assembled and all 4 has the problem.

3.In a board where the problem is seen, is the problem intermittent or permanent?

The problem remains permanently.

4.If the problem is intermittent, how often is it seen?

Permanent.

5.Is it possible to reproduce the problem easily?

Yes, it occurs every time.

6.Is this seen in a device that has been working fine for some time? If so, how long?

As mentioned, these specific boards has failed since first tested. But the same board design from previous batches worked fine.

7.Does the code work fine with the JTAG connector connected? 

The same thing occurs when connected with JTAG.

8.Is it possible to reproduce the problem with CCS-JTAG connected?

Yes, same thing happens. As described above, when connected via CCS I can load the M3 successfully. Then I load the C28 also just fine. A soon as I click run on the C28 a reset occurs on both cores.

9.Does it make a difference to run the code from Flash as opposed to RAM? From your post, it appears there is.

No, sorry for confusion. The same occurs running from RAM or from flash. 

10.Are the levels of the boot-mode pins correct while the device is coming out of reset (and when the boot-ROM takes a snapshot of those pins)?

On my circuit the boot pins are all pulled high with 2.2k permanently, which selects boot from flash.

11.Is there any temperature dependency to the issue? i.e. does the rate of problem occurrence vary based on the ambient temperature?

I did not specifically test under different ambient temperature but it seems that the issue occurs regardless of temperature.

12.Can you try the most recent CCS version ? 

I have tried the latest CCS ver 10 and still the same thing happens.

Here is the link again:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/788207/ccs-f28m35h52c-concerto-c28x-core-gets-disconnected-when-m3-is-reseted

Thanks

Albert

A logical conclusion is that there is a build error on this latest batch of the board with some capacitor or resistor related to the chip startup perhaps being the wrong value. However, all the relevant components seems correct. I obviously can't check the caps in circuit, but I have done a few spot checks by removing the caps. Which external components could cause a problem like this if being the wrong value? Here are the relevant sections of the circuit:

Considering this design has been working fine for a few years and nothing has changed in the board or the software, we can only suspect something that went wrong with this particular build (as you yourself surmised). Have you checked the boot-mode select resistors (R32 to R35)? 

One thing caught my attention, although it may not be connected to this issue: The datasheet recommends tying ARS & XRS together, but I see ARS left unconnected (unless the connection is not shown in the schematics).

Yes, the problem is that I have check all the surrounding components that could possibly cause it and they all are correct. Hence my question, what would cause the C28 to reset after program running?

Just some more information:

- The same problem occurs even when loading a standard Blinky program.

- If I only connect to the device and load everything seems fine. Only after the C28 program runs, the reset occurs. So its not a permanent condition from power on. If it was due to external components I would have expected the condition to be present directly from power on.

- When the reset occurred and I only connect to the device with CCS without loading any program, I can view the RESC register:

This bit refers to a reset due to XRS pin. But there is nothing externally on the XRS pin that caused a reset. I have even disconnected the caps on the reset circuit. Something internally is pulling the XRS pin low if I view it with a scope. I can't find the CRESC register to see what the C28 reset cause is. Are there other registers that could help in fault finding? I can't find the Boot mode registers, where do I find them?

Regarding the reset circuit, the wiring there was not done properly, but ARS is essentially connected to XRS via the 0 ohm resistor.

You mentioned 128 Hz in the first post. This could point to the watchdog (the 28x does not have a WD on its own ; it does have the NMIWD) on M3. 

Is it possible to solder a known-good device in a new batch PCB and a suspect device in a known-good PCB? It would be good to determine if the problem follows the device or the PCB.