Forums

Hi everyone,

I tried to change the boot strap from "flash" to "SARAM" and here's what I got on the console when I enter in debug mode:

C28xx_0: Flash Programmer: Warning: The configured device (TMS320F28335), does not match the detected device (). Flash Programming operations could be affected. Please consider modifying your target configuration file.
C28xx_0: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx_0: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx_0: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx_0: Breakpoint Manager: Retrying with a AET breakpoint
C28xx_0: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x9081: (Error -1066 @ 0x9081) Unable to set requested breakpoint in memory. Verify that the breakpoint address is in writable memory. (Emulation package 5.0.681.0)
C28xx_0: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.

The current program in flash (that was ok before the crash) seems to corrupt the chip.

Even if I boot in SARAM, I still cannot erase the flash with the On-Chip Flash utility in Tools menu. I didn't change the password so it is not supposed to be protected or locked.

N Luna

(CCS freezed while I was debugging)

Were you programming or erasing the device when this happened?  

N Luna

I found that one of the 2 DSP is in a bad state and the pin XRS\ is going low for 10usec and high for few msec. I found in the datasheet that the watchdog will drop XRS\ pin for 512 * OSCCLK if not kicked. In my case 512 * 50Mhz = 10usec, so it seems to fit with what I see on the pin.

Yes it does sound like the watchdog. 

N Luna

Also, the chip holds TDO to solid one so it breaks the JTAG chain. When I put that DSP in reset (by holding XRS\ to GND), I am able to program or debug the other one.

There is a security mechanism on this device that will disable JTAG if the password is set to a non "all F" value.  You can connect to such a device by either booting to the "wait" (it might be called boot to check mode on that device) or by holding the device in reset like you have done.

It sounds like you are able to connect and debug if you do this.  I'm surprised you can program the flash, though.  If the password was set somehow you would not be able to program the flash.

Can you double check all of the power pins - in particular the VDD3VFL pin?  This  pin powers the flash so it can appear to be locked if it is not powered properly. 

Is this device on an eZdsp with a socket?  If so please check the device connections.  I've seen these devices get lose in the socket and not make a good connection leading to very strange behavior.

If you were programming  / erasing when CCS crashed then it is possible that the password was left in an unknown state - which would lock the device.

Lori Heustess

There is a security mechanism on this device that will disable JTAG if the password is set to a non "all F" value.  You can connect to such a device by either booting to the "wait" (it might be called boot to check mode on that device) or by holding the device in reset like you have done.

Yes, I also tried this mode and I still cannot erase/program the flash. It "repairs" the jtag chain because the broken chip release TDO,but I still cannot access to the flash.

Lori Heustess

If you were programming  / erasing when CCS crashed then it is possible that the password was left in an unknown state - which would lock the device.

No I was tracing the code with the debugger. I'm not on a eZdsp, it's a custom board.

After few tests it seems that the flash is locked.. I'm wondering how could this happened if the erase/program step never went wrong..

I assume that without the password my only option is to replace the chip ?

N Luna

After few tests it seems that the flash is locked.. I'm wondering how could this happened if the erase/program step never went wrong..

Have you checked the power rails?   A program/erase mishap or a bad power rail can cause a locked device.

N Luna

I assume that without the password my only option is to replace the chip ?

Yes unfortunately - if we try all debug options and it really is locked then there is no way to recover this device.

Power rails are good.

You think that it's possible that a short on power rail could have locked the device ? 

N Luna

Power rails are good.

You think that it's possible that a short on power rail could have locked the device ? 

My thinking was more the VDD3VFL - it powers the flash where the password is stored.  So if it is not healthy the password will not read back correctly.

-Lori

Hi Lori,

Well I have 2 chips on my board and they both share the same 3V3 / 1V9. One chip is working and not the other one. 

I have monitored the power rails and they are both good.

For now, I have 2 boards "bricked" I changed the faulty chip on one of the two boards and it is working now. 

I suspect the flash might have been corrupted... but I would like to find why it happened so easily.

Nicolas

Ok. Thanks for the support.

Lori,

I'm the local disty covering them. Can you tell me how to ship the parts back..

Thanks,

Alex

Lori,

I also have the schematic if this could help you out. Contact me directly so i can't send them to you. Customer does not want them public on e2e.

Thanks,

Alex