TMS320F28335: After reprogramming flash through bootloader, program does not run, cannot reprogram with Uniflash, cannot Test Connection using CCS

Stefani,

I am working on your question right now, I have to consult a Flash programming expert about this. I will be getting back to you shortly.

Regards,

Peter

Stefani,

Could you check if you have a similar issue like this ? -> https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/888736?CCS-TMS320F280049C-TMS320F280049C-not-able-to-flash-2nd-time

Also, is the device secured?

Thanks and regards,
Vamsi

Thank you Peter.  I will read through Vamsi's suggestion.

Thank you for replying, Vamsi, I appreciate it.

No, the device is not secured.   The problem is somewhat similar, except we have had the custom board for several years and most of the time we can flash it successfully.  Sometimes we flash using XDS200, sometimes we flash by sending data over through CAN bus (from another board).   The failed boards were working before, but when the firmware was updated they become "bricked".

Vamsi, you suggested:  "FYI: You should still be able to program the Flash in wait-boot."   Does that mean changing it in hardware how the boot mode pins are connected?  All 4 are normally pulled high.

Thank you.

Stefani,

Your new firmware might be driving the JTAG pins causing contention - please check.

Regarding my suggestion on the wait-boot: Yes, keeping the device in wait-boot keeps the ROM spinning in a loop instead of jumping to application - helps to establish a reliable connection. 

Thanks and regards,
Vamsi

Vamsi,

The new firmware can be programmed to other boards and it runs well as well as being able to be reprogrammed again using CAN bus or JTAG.  Therefore I don't think the issue is in the firmware.

The bricked DSP probably has a bad program (corrupted firmware) because something happened during the firmware update.  My goal is how to reprogram the flash with known good firmware again.

I tried to pull down GPIO84 and GPIO85 to GND (instead lf pulled up to 3.3Vdc) and I can get a successful "Test Connection".  Then we tried putting a wire for those pins but then it required keeping the board in reset (XRS~) to get successful Test Connection.

After I had a successful Test Connection, I would try to use CCS to load program and debug, but I would get Load failure.

I think I am not clear what are the steps required to reprogram a flash with a bad firmware.  What combinations of the 4 pin boot mode (GPIO84-GPIO87)  should it be (I chose Wait in Boot Mode, which means GPIO84 and GPIO85 low and GPIO86 and GPIO87 high).  Does it need to be kept there?

When it passes Test Connection, I should be able to Debug (Bug icon in CCS) or Load Flash from CCS, correct?  How should the GPIO boot mode be connected?

Thank you.

Noticed that GPIO86 and GPIO87 are the ones needed to be low for "Branch to Check Boot Mode".  Correcting that now.

When we fixed the GPIO boot mode pins, it is now happily pass Test Connection.

When debugging / download to flash the code, I get "Load Program Error" and the Console will display the following:

C28xx: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx: 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: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled.
C28xx: File Loader: Memory write failed: Unknown error
C28xx: GEL: File: C:\........DSP.out: Load failed.

How to check Device is unlocked or locked in CCS?  What does the detected device show?  I am sure it is a  TMS320F28335.

Stefani,

Glad the connection test passed now.

Did you create the target configuration file using TMS320F28335 device XML (device that you choose when creating this file)?

Instead of loading code to flash, did you try to load to RAM and execute to see if that is successful?  If not, please try and let us know.

Regarding the device lock status:  In the debugger memory window, please enter the password address locations and see whether it is all 0xFFFFs or not.  All 0xFFFFs is unlocked.  

Thanks and regards,
Vamsi

Vamsi,

I did create the target configuration:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="Texas Instruments XDS2xx USB Debug Probe_0">
<instance XML_version="1.2" desc="Texas Instruments XDS2xx USB Debug Probe_0" href="connections/TIXDS2XXUSB_Connection.xml" id="Texas Instruments XDS2xx USB Debug Probe_0" xml="TIXDS2XXUSB_Connection.xml" xmlpath="connections"/>
<connection XML_version="1.2" id="Texas Instruments XDS2xx USB Debug Probe_0">
<instance XML_version="1.2" href="drivers/tixds560c28x.xml" id="drivers" xml="tixds560c28x.xml" xmlpath="drivers"/>
<platform XML_version="1.2" id="platform_0">
<instance XML_version="1.2" desc="TMS320F28335_0" href="devices/f28335.xml" id="TMS320F28335_0" xml="f28335.xml" xmlpath="devices"/>
</platform>
</connection>
</configuration>
</configurations>

Is that correct?

Loading to RAM, that means changing the .cmd command being used, correct?  Let me see what I can do.

For the debug memory window, on the bricked board I cannot see anything.  When I try to debug, it failed like I described above.  Is there a way to seeing the flash without debugging?

On a good board the password address location is all 0xFFFF.

Thank you.

Stefani,

Regarding the target config file: Are you using XDS200 or XDS560?  

Regarding the RAM load: Yes, that's what I meant.  But, based on what you said, if you are not able to connect to the device, you will not be able to load the code to RAM.  

I feel that the firmware update process on the failed board might have corrupted the password locations and hence the device is locked.

Thanks and regards,
Vamsi

Vamsi,

Somehow my .cproject was bad?  I went around and around to debug, so I can see the CSM_PWL memory.  I at first managed to get it by commenting out ADC_cal() in the gel file.  Then I put everything back and it is now working (meaning I can debug without Load Program Error).

Unfortunately this is what I saw: 

That means it is locked, correct?  Is there a way of unlocking it or erasing somehow?

Thanks Vamsi.

If you cannot see the screen capture, it is all zeros for address 0x0033FFF8 through 0x0033FFFF.

Vamsi Gudivada said:

Stefani,

Regarding the target config file: Are you using XDS200 or XDS560?  

.....

Stefani,

Yes, I am not able to see the screen capture.  If it is all zeros, then it is locked.  We need to know the password to be able to unlock it and reprogram the device (assuming you don't have flash API embedded in the application).  If the passwords were programmed as 0, then it gets permanently locked. 

If the same application is working fine in other boards, then I don't think it is a problem with your application.  If not, I would have asked to check the map file just to make sure that nothing is mapped to the password locations in any of your recent changes to the application.  

Maybe, something went wrong during the last upgrade corrupting the password locations.

Thanks and regards,

Vamsi

Stefani,

Regarding the emulator:  That is fine. XDS200 is implemented using those drivers. I can confirm with our emulator team if needed.

Thanks and regards,
Vamsi

Vamsi,

Then the only way to recover it will be to replace the DSP, correct?  

There is a flash API embedded in the application, that is how we update the software through CAN bus from another board.

There is an UnlockCSM function being called.  We don't really have Secure Module, so essentially we never want to ever lock it.

I saw in DSP2833x_CSMPasswords.asm the following code:

;----------------------------------------------------------------------

; For code security operation, all addresses between 0x33FF80 and
; 0X33fff5 cannot be used as program code or data. These locations
; must be programmed to 0x0000 when the code security password locations
; (PWL) are programmed. If security is not a concern, then these addresses
; can be used for code or data.

; The section "csm_rsvd" can be used to program these locations to 0x0000.

.sect "csm_rsvd"
.loop (33FFF5h - 33FF80h + 1)
.int 0x0000
.endloop

Instead of .int 0x0000, if I change it to 0xFFFF  means that CSM is not in use, correct?  Making those zeroes will indicate that CSM is in use and then if the CSM_PWL at address 0x0033FFF8 through 0x0033FFFF somehow gets corrupted then we get a bricked DSP?

Thank you for being so patient in answering my questions.

Stefani,

If the password locations are all 0s, then you can't unlock the device anymore.  However, since you have Flash API embedded in your application, you can trigger your application to erase the flash (and hence the password locations) and thus unlock.  This should work. 

Regarding the csm_rsvd question: If an application wants to use security and program passwords at the 128-bit password location in Flash (at 0x33FFF8 - 0x33FFFF), then it has to reserve a few more locations (address range 0x33FF80 -  0x33FFF5) as well and program 0x0000 in there.  If security is not a concern and don't want to program a password at address range 0x33FFF8 - 0x33FFFF, then the address range 0x33FF80 - 0x33FFF5 may be used for code or data.   

csm_rsvd you copied is used for these reserved locations and not the passwords itself.  Programming 0x0000 at these locations itself does not mean that CSM is in use.  Even if you program 0x0000 in these reserved locations, if you don't program non-all 1s password at password locations, device will not be secured.  Programming 0x0000 at these reserved locations help to keep the security robust and is a must when passwords are programmed with a value other than all 1s. 

If you have further questions on security, please open a new post and we can assign it to our security expert.  Thank you.

Thanks and regards,

Vamsi

Vamsi Gudivada said:

If the password locations are all 0s, then you can't unlock the device anymore.  However, since you have Flash API embedded in your application, you can trigger your application to erase the flash (and hence the password locations) and thus unlock.  This should work. 

The password location 0x0033FFF8 through 0x0033FFFF should be all 0xFFFF.  If I strap the bootmode to "Branch to Check  Boot Mode" (GPIO86 and GPIO87 strapped to ground) then I can pass "Test Connection" and debug in CCS.  If I try to erase flash I get:

28xx: GEL Output:
ADC Calibration not complete, check if device is unlocked and recalibrate.C28xx: 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: Erasing Flash memory...
C28xx: Flash Programmer: Error erasing flash memory. Device is locked or not connected. Operation cancelled

If I try to erase flash using Uniflash, I get this:

Even if you program 0x0000 in these reserved locations, if you don't program non-all 1s program at password locations, device will not be secured.

Vamsi,

I am confused here, non-all 1s at password location means device is secured, correct?

Regarding the csm_rsvd question: If an application wants to use security and program passwords at the 128-bit password location in Flash (at 0x33FFF8 - 0x33FFFF), then it has to reserve a few more locations (address range 0x33FF80 -  0x33FFF5) as well and program 0x0000 in there.  If security is not a concern and don't want to program a password at address range 0x33FFF8 - 0x33FFFF, then the address range 0x33FF80 - 0x33FFF5 may be used for code or data.   

So it doesn't matter what unused values is programmed at the csm_rsvd area.  The password location determines whether the device is secured or not, correct?

Is there a way to make it never ever secured?

Thanks Vamsi.

Vamsi,

1. My mistake, I did not pay attention that it was "don't" and "not".  Got it.  All 1's means unsecured.

2. Got it.

3.  So when the board / DSP is bricked, I can no longer communicate with the board.  I don't know if the code is still in Flash. We have a blinking LED to indicate that the firmware is running and it is not blinking anymore and nothing seems to respond.

4.  Understood.  At first I thought we reset the boards too early, but even without reset I managed to brick another board today with a particular firmware version.

Thank you so much for your help, Vamsi.  I think I have accepted the fact that something happened to the board while programming and there is no recovery except for replacing the DSP.   I thought the reset is the culprit, but I think there is something else.

I will consider the issue "resolved" for now.

Stefani.