TMS320F28377D: Issues Programming Flash related to Setting PLL Registers

Hi Laurent,

Does this happen for all the new boards?  Could you try swapping a device from the failing board to a passing board?

Thanks and regards,

Vamsi 

It does happen on a few set of boards.

I am afraid that swapping devices will be difficult, time consuming and costly (we can't do it in house) and I am hoping it will be the last resort.

What I can add to the troubleshooting clues is that I am able to step into a program loaded in RAM with a frequency clock no greater than 40MHz. I am using the internal INTOSC2 with a PLL set to x4.  As soon as I increase the PLL to x5 (50MHz) the device crashed after enabling the PLL (Flash programming is also using INTOSC2 with a PLL).

I also decreased the JTAG frequency to 100KHz but as I expected, it didn't change the outcome.

Could you please describe the physical phenomenon that occurs upon frequency increase? What should we look for? increase of power, noise...

Thank you for your help.

Laurent

Hi Laurent,

Laurent Z. said:

A break through during troubleshooting was when we were able to connect to the DSP with JTAG. We can step into a program loaded in RAM, everything run fine until we reach the instruction that set the PLL in order to increase the SYSCLK to 200MHz.

InitSysPll(XTAL_OSC,IMULT_20,FMULT_0,PLLCLK_BY_2) ;

Can you elaborate on the above? Some related questions:

1. What is the frequency of your external oscillator / crystal? Want to make sure it's within spec.
2. Are you saying that even when running from RAM there is a JTAG disconnection once the PLL is configured for 200MHz? With using external oscillator.

Laurent Z. said:

Therefore, with this piece of information in mind, using UNIFLASH, we lowered the Flash programming clock to around 95MHz and we were able to program the FLASH. I don't think this is a solution since it never happened to us before. Although, it is a new set of custom boards to be programmed, the design hasn't changed for years and we don't feel comfortable with this approach especially that after programming we basically can't connect to the DSP via JTAG anymore and get the following error message:

You can try following the steps in the App Note below when the above condition happens. Putting the device in wait boot mode may allow you to connect.

https://www.ti.com/lit/spracf0 

Laurent Z. said:

What I can add to the troubleshooting clues is that I am able to step into a program loaded in RAM with a frequency clock no greater than 40MHz. I am using the internal INTOSC2 with a PLL set to x4.  As soon as I increase the PLL to x5 (50MHz) the device crashed after enabling the PLL (Flash programming is also using INTOSC2 with a PLL).

The above makes it sound like a power related issue. Are the current capacities for the 3.3V and 1.2V rails sufficient for the device in all working conditions (flash programming is usually a higher power consuming task).

Best,

Kevin

Laurent,

Agree with Kevin that this sounds like a power-related issue. One thing I want to confirm - what decoupling caps do you have on the VDD and VDDIO pins?

The PLL configuration looks fine (assuming the crystal frequency is 20MHz).

Ibukun

Kevin,

Kevin Allen18 said:

• What is the frequency of your external oscillator / crystal? Want to make sure it's within spec.
• Are you saying that even when running from RAM there is a JTAG disconnection once the PLL is configured for 200MHz? With using external oscillator.

The external oscillator is a 20MHz crystal that is within the specs but to make sure I bypassed this external clock by using the internal one during PLL setup.

Correct, the program in RAM executes until it reaches the InitSysPll(XTAL_OSC,IMULT_20,FMULT_0,PLLCLK_BY_2) instructions, precisely the PLL enable instruction SYSPLLCTL1.PLLCLKEN.

Kevin Allen18 said:

The above makes it sound like a power related issue. Are the current capacities for the 3.3V and 1.2V rails sufficient for the device in all working conditions (flash programming is usually a higher power consuming task).

To make sure of this we connected the 3.3V and 1.2V directly to a lab power supply, because we believed it was the issue.

Each 3.3V VDDIO and each 1.2V VDD have a 100nF capacitor.

Which power rail should we focus on?

VDDIO, VDD, VDDOSC, VDD3VFL...all?

Those are huge caps, need to be sure power supply sequencing/ramp rate requirements are still being met. Only 20uF bulk cap is needed for each power rail.

One other question -- have you changed from an older SDK (e.g. ControlSUITE) to newer C2000Ware? We've seen in the past an issue where the device support headers were not correctly migrated, leading to a failure when the PLL was configured. (However, this should not affect UNIFLASH, so I still think a power-related issue is most likely).

Ibukun

Ibukun Olumuyiwa said:

Those are huge caps, need to be sure power supply sequencing/ramp rate requirements are still being met. Only 20uF bulk cap is needed for each power rail.

We used the same values as the dev board we have been prototyping with.

Kevin Allen18 said:

You can try following the steps in the App Note below when the above condition happens. Putting the device in wait boot mode may allow you to connect.

I would love to change this value in RAM, location 0xD00, but I can't even connect to the target in CCS to get access to it. 

Hi Laurent,

Did you follow all steps in the App Note to try and connect to the device OR did you get stuck at any step? Have you verified the state of XRSn to be high after power up?

Best,

Kevin

Hello Kevin,

I tried, but I am stuck at the step where XRST should stay high. We are getting this error message, with no way to connect to the target:

I noticed something strange though. Although, the TRST pin is high, the XRST is pulsing high and low with a 6ms period since we are not servicing the watchdog. My understanding was that when we connect with the JTAG, The TRST would be high and would prevent the DSP from resetting. 

We do have a pulldown on the TRST.

Laurent,

Just want to check a couple more things:

- How are your boot mode pins configured? If you try putting the device in SCI boot mode, are you are able to connect and program Flash?

- Earlier you mentioned 100nF supply caps. Please try reducing these caps as they are definitely too big. 20uF is what we recommend.

Best regards,
Ibukun

The Boot mode is currently configured as Get/Flash. I am going to try Wait or SCI and I will let you know.

Are you suggesting to replace all the 100nF decoupling capacitors from 100nF to 20uF (Isn't 100nF already smaller than 20uF)? Or are you talking about the sum of all of them should not exceed 20uF? 

Laurent,

Sorry, I got my units crossed for some reason, somehow my mind translated n as m. 100nF is too small. Minimum bulk cap on the supplies is 10uF, but 20uF is recommended. The small 100nF caps should be placed on each pin, but in addition a bulk cap of 20uF is required. This applies to both VDD and VDDIO rails.

Best regards,
Ibukun

So we changed the Boot resistors to boot into "Wait Mode" which helped connecting to the target. It seems that after programming the board at low frequency, the software trigger a DSP crash and a reboot once the InitSysPll() instruction is executed.

We increased the bulk capacitors to 20uF on all power rails (VDDIO, VDD, VDDOSC, VDD3VFL) but no improvement.

We are still investigating what could disturb the power rails and we welcome any suggestions that would allow us to troubleshoot this issue.

Thank you very much for your help.

Best regards,

Laurent

Hello Laurent,

Please put a breakpoint in InitSysPll(), right after the write to SYSPLLMULT. Can you show the contents of the following registers:

• CLKSRCCTL1
• SYSPLLCTL1
• SYSPLLMULT
• SYSPLLSTS
• MCDCR
• X1CNT

Thanks,
Ibukun

Before:

After

Thanks Laurent. It looks like the PLL registers are being successfully written and the PLL is getting locked. So the issue is happening when the rest of the SoC is switched on to the PLL output clock. This again points to a power-related issue (high frequency = high power draw). We'd probably like to see a board schematic at this point to help diagnose the issue further.

Also, has this been tested on multiple units, and have you done any A/B testing with respect to board & MCU units?

Best regards,
Ibukun

Let me check with management but I think I am going to take on your offer to check the schematic because we tried many things for the past two weeks and we are very stuck.

We do have an NDA with TI and if you don't mind I will move this conversation to a private chat with you!

Thank you so much.

Laurent