TMS320F28235: Flash erase returns error code 22 from sector F

Hi Jordan,

Have you tried running the Depletion Algorithm in the On-chip Flash tool in CCS to see if it passes OK? Not certain if it's any different than the API function, but may be worth a try.

Jordan Zhou said:

With CCS code, it reads the space and all data are 0x0000. 

If you can read all other flash sectors in CCS OK then sector F is all programmed to 0's.

Jordan Zhou said:

With CCS code, Flash_DepRecover() was called and passed without any error. After that, I tried to erase with CCS code or CCS "On-Chip Flash" tool, both failed.

The sector erase is timing out after some time of attempting to erase then?

Best,

Kevin

Kevin,

"The sector erase is timing out after some time of attempting to erase then?" I don't understand. 

You are right, all other sectors can be read and write, except F. 

Customer needs a reply on this issue. What can we do to identify the issue? Is sector F broken?

Br, Jordan

Hi Jordan,

The error code 22 you are receiving is caused by the erase operation not being able to be completed with the maximum number of pulses:

See the following flash FAQ answers for more information on this:

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/758747

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/757586

Based on the answer in the 2nd link above, it sounds like the sector is possibly in depletion, but you said that running the Flash_DepRecover() API function passes with no errors. You're saying the function returns a value of of STATUS_SUCCESS (equal to 0)?

Can you try running the depletion recovery routine from the 'On-chip Flash' tool instead of using the Flash API function within code to see if it passes?

Best,

Kevin

Kevin,

Today we tried "depletion recovery" through "on-chip Flash". Recovery completed successfully, which is the same as I did through Flash API.

After that, sector F still can't be erased. It's the same as before. 

We also try to power customer's board with another low ripple power supplier, the same result.

What can we do now? Can we confirm that, sector F is broken?

Another question, in which case, it can cause this issue? This chip is used in traction. It will be erased only 5 times each year. 

Br, Jordan

Hi Jordan,

OK, thanks for trying the additional tests and providing more details.

Did sector F of this device erase and program correctly anytime before this issue started to occur? Was the flash erase or depletion operation interrupted at any point prior to the issue occurring? Is there anything specific that happened to the device between the time the sector erased properly and now?

I'm discussing internally to get a second opinion, however it sounds to me like flash sector F is in a state that can no longer be erased or recovered. That the erase API function times out after the max number of erase pulses on the sector.

Best,

Kevin

Kevin,

Here's the reply:

Did sector F of this device erase and program correctly anytime before this issue started to occur? Was the flash erase or depletion operation interrupted at any point prior to the issue occurring? Is there anything specific that happened to the device between the time the sector erased properly and now?

Re: Yes, sector F worked well before the issue. It's used in a traction for about 1 year. As I said, 5 times' Flash erase happenes each year. A pity that it happened this month. During Flash erase, there's no interrupt. All tasks are stopped, but only our Flash API. If API returns an error, user code will not try to erase again, but report a system error. Customer took it back and did several test through JTAG and test code, trying to erase and recover Flash. All other sectors work well (can be erased and programmed), but not sector F. 

As mentioned before, error code 22 was returned, and all data in sector F are 0x00. The erase steps are as 4 below. Which is the actual step erase operation go to, after error code 22 returned? Step 2 or step 1?  If step 1 is done successfully, does it mean that there's no over erase in sector F?

1) Pre-compact – makes sure no bits are in an over erased state.
2) Clear – Programs all bits in the sector to 0.
3) Erase – Sets all bits in the sector to 1 and
4) Compaction - Corrects any “over-erased” (depleted) bits.

Any way, based on current test, what can we do?

Customer is waitng for a reply: 
1) What's the rout cause of the issue? Official reply.

2) Is it random? 

3) Does other F28235 (they used in traction) have the same risk? 

Thanks a lot.

Br, Jordan