SM320F28335-EP: Flash programming API fails and flash cannot be recovered

Hello,

To correct the statement from above:

Both steps were performed with the Lauterbach. (I just got the confirmation of my team, sorry for the inconveniences) 

Some more details:

we are using the library Flash28335_API_V210.lib from the C2000Ware v:2.00.00.03. After having this failure: We tried to execute the memory loader that was loaded to the target on the first load without success. Then we created a little RAM executable with CCS and loaded it with Lauterbach. There we got the following error codes when executing the following functions:

• Flash28335_DepRecover 23
• Flash28335_Erase 24
• Flash28335_Program 30

(On the evaluation board there is no problem with this executable. The error code is 0 for all cases.)

We have this issue with one and probably with a second of seven pre-production (zero series) boards (to be confirmed until the end of the week). 

Can we recover from this point? What brought us into this situation?

Best Regards

Sebastian

Sebastian,

If the flash programmation is working on the eval board( I assume the F28335 control CARD) and not on the final production board, I would look at the support pin connections and any differences between the 2 PCBs.

This would include:

All VDDIO, VDD, VSS pins, especially VDD3FL as this is the flash power pin

If the above are all schematically the same as the eval board, we may need to look at their stability when the device is running, in this case you could also compare the decaps used in addition to probing the bus.

TEST1 and TEST2 should be floating(this is also for the flash)

The clock pins, either XCLKIN or X1 or X2 and whichever is not used is tied off according to the DS.  Is the input frequency the same as the eval board

Boot pins are set the same way(assuming the custom bootloader is invoked from power up)

JTAG pins are terminated in the same manner

XRSn pin is controlled in a similar manner

Best,
Matthew

Sebastian,

More generally it is also make sense to double check your HW against the HW design guideline we provide:
Hardware Design Guidelines for TMS320F28xx and TMS320F28xxx DSCs (Rev. D)

BR,

A.

The potential damaged second unit is fine. The setup of the supplier to load the software was not correct. 

There may have been a voltage drop because of the current limiter of the external power supply during the flash procedure. Can this be the reason for the problem?

Is there anyway that this board can be saved?

Sebastian,

If the device is locked due to the current limit, i.e. the flash operation programmed something non- 0xFFFF in the CSM password locations, then the device is considered permanently locked and cannot be recovered. 

You can check that this is the case with JTAG connection and looking at the CSM passwords in memory.  If you read back all 0x0000, then the device is locked.  If you read 0xFFFF, then there is some other issue than CSM programmed causing the after effects.

Best,

Matthew

Hi Matthew, the device is not locked since the debugging of the code loaded during the first flash operation works without problems. When we load a minimalistic demo program using the flash library we get following error codes:

• Flash28335_DepRecover 23
• Flash28335_Erase 24
• Flash28335_Program 30

On another board this application returns 0s only. In addition the erase and programming was successful. Therefore, do you have any ideas?

Best Regards,

Sebastian

Sebastian,

Can you clarify on the "bad" device, are you able to connect and just execute the "erase" option from CCS/Uniflash?  It is only when loading the demo there is an issue?  Or currently is the device un-able to erase as well.

Best,

Matthew

The device having problems is our custom device. That we flash with Lauterbach and afterwards we have the option to load software with the a resident memory loader. It failed after we tried to load something a second time with the Lauterbach. In order to investigate I created a little executable to be executed from RAM that reports the errors above. On another custom device (same HW) I got not no errors. I did this to double check my test.

Sebastian,

On your custom device today, you can connect with CCS and verify that it is not locked, but it is not possible to flash new code through the Lauterback, correct?  If the device is not accidentally locked I would not expect a persistent issue with flashing the device.  However, if the tool is consistently reporting that erase failed and depletion recovery is not working, then we have gotten the flash into an undefined state.  I believe the same root cause would apply here.

Best,

Matthew

Hi Matthew, we cannot connect with CCS since we do not have a debugger. When using a Lauterbach:

• We can debug normally: Memory is visible and you can step through the code => device is not locked
• When we try to flash something else => Trace32 reports an error

=> Therefore I think the device is in an undefined state. Can we recover from this?