TMS320F28379S: Emulator Cannot Program Flash

Hi Ed,

Have you been able to connect and flash the device previously? Could you try putting the device in wait boot mode? 

Best Regards,

Ben Collier

Hi Ben,

In the past, I have been able to connect and flash the device on multiple HW platforms. This is a new HW design which is essentially a new form factor for an existing and working design. I feel that there must be a HW difference, but it is escaping me. In the area of the JTAG, both sets of schematics are identical.

Yes, I tried Wait Boot Mode with no luck.

BTW, this happens using multiple copies of the emulator.

I don’t know if this matters, but in the initial post, I mentioned that I could put the system into a passive mode and only load symbols. Since then I have been working with it, and have found that after running it, and collecting information, if I try to stop it, I will get the same low power fault. If I close the debug session and connect again, it has always succeeded.

Another clue… The device is running code due to the fact that the initial use of the uniflash files worked using the same type of emulator. And I can update code using our normal code download process.

When the debugger tells me that it thinks the device may be operating in low power mode, what information is it using to make that assessment?

Thank you,

Ed

Hi Ed, Ben is OOO, hopefully he'll be able to reply later this week.

OK.  Thank you for the heads up.

Ed

Ed,

Could you try the 'Test Connection' option inside of the menu for the Target Configuration? 

If that passes, then the JTAG schematic/layout is probably fine. Next it would be good to look at you power rails and XRSn circuit. 

Best Regards,

Ben Collier

Hi Ben,

I was able to solve the problem for which I needed the emulator connected.  Unfortunately, because of that, I needed to relinquish the hardware so that others could use it.  So this will need to wait.

But I did get another clue.  When I added some dummy code at the start of our code to do unlock the DSP, then the intermittent problems went away.

When I connect and try to burn the flash, our GEL script unlocks the core and does so at OnTargetConnect().  Is that the right place to do it, or is there an earlier place I should be using?

Thank you,

Ed

Ed,

Ed Sanders said:

But I did get another clue.  When I added some dummy code at the start of our code to do unlock the DSP, then the intermittent problems went away.

Ok, did you setup any security on this device in the past? 

Best Regards,

Ben Collier

Yes.  It was locked when it was first built.  Do you think that is why I can't connect and burn the flash?

Thank you,

Ed

Hi Ed, unfortunately Ben is OOO this week.  He should be able to get back to you early next week.  I appreciate your patience and apologize for any inconvenience.

No problem.  I assume this thread will stay alive so we can continue when Ben returns?

Thank you,

Ed

yes, the thread won't lock until there has been no activity for 30 days.  

Hi Ben,

Unfortunately, I fixed the issue we were having, and needed to relinquish the hardware so that others could use it.

But if I understand the App Note correctly, this is doing what our code would normally do, but before anything else is done?  CCS would then use it to unlock the drive prior to doing anything else with it thus avoiding the errors?

Thank you,

Ed

Great!  Thank you Ben.  If I get the HW back, I will give it a try.

Thanks again,

Ed