How would F2812 Device lock when reset happens during program/erase sector I/J while CSM_PWL is mapped to sector A

Hi Henry,

Henry Ng said:

however, i do not erase/program sector A in my application, but only play with sector I & J.

how would a reset happens during program or erase with sector I & J impact the password setting in sector A?

can you please help me to understand this?

Nice thought, there should be no impact according to this article which says "For example, if power is lost during the erase of sector A, where the CSM passwords are located, then the device may be permanently locked and the recovery algorithm cannot operate on the flash." here:

http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Depletion

Regards,

Gautam

Henry,

If program / erase operation is interrupted when working on Sector J it can possibly affect Sector A. If sector J is depleted, it is possible for device to lock as sector A password memory reads might show different password.

The reasoning for this boils down to how flash cells are physically architectured.

Sector J and Sector A are balanced sectors. These sectors are depended on one another for proper read operation. Essentially what this means is reads on memory location on sector A depends upon corresponding memory location in Sector J.

Regards,

Manoj

Hi Manoj,

Thanks for your help.  However, i am a bit confused on this.

When you said "read", does it mean regular read or it is a pre-compaction operation.

I found the flash API v2.10 pdf file (attachment) 

8420.Flash281x_API_V210.pdf

If you read this document page 31, it said about what happen to the flash sectors during erase phase.

In the pre-compaction, it said that the precompaction will occur to "all" sectors.  A precompaction will clear all bits in the sector to 0.  So because precompaction happens for all sectors, technically, sector A will be affected even if i don't tell it to erase sector A.  So, if there is a power glitch or whatever can happen during this pre-compaction time of sector A, the device may be locked up because of random values for the password.

Since we know we only need to mess with two sectors, is there anyway we can instruct the erase function or call another erase function or configuring the erase function not to do pre-compaction for all sectors but only the sectors that user wants to erase?  The precompaction all sectors cause issue for user.  I don't really understand why precompaction has to be done for all sectors if we only want to erase sector J & I.  but i think this is what happening that cause my device to lock out. 

One clarification is that even if my device is lock (non-recoverable), it can still function normally (as long as i don't mess with sector J & I) in my system.  

Thanks,

Henry

Hi Manoj,

Actually another thought just come up.  You said that "Sector J and Sector A are balanced sectors. These sectors are depended on one another for proper read operation. Essentially what this means is reads on memory location on sector A depends upon corresponding memory location in Sector J."  

So, the question is that is there any other sector that is not balanced to each other like you said above?  

Reason is that if there is a sector like that, i can map my CSM password there and avoid being infected by the other sectors.

Thanks,

Henry

 

Hnery,

CSM passwords SHOULD ONLY be programmed @ 0x3F7FF8 - 0x3F7FFF which is in Sector A.

In F2812, all the sectors are balanced with one another.

• SectorJ and Sector A are balanced sectors to one another
• Sector I and Sector B are balanced sectors to one another
• Sector H and Sector C are balanced sectors to one another
• Sector G and Sector D are balanced sectors to one another
• Sector F and Sector E are balanced sectors to one another

Regards,

Manoj

Henry,

Regarding your question on pre-compaction:-

I believer you have confused pre-compaction with pre-conditioning. These are completely different steps.

Pre-compaction:- Pre-compaction does happen on all the flash sectors. But, unlike what you mentioned in your message, precompaction doesn't clear all the bits in sector to 0. As mentioned in the API document, precompaction is more of recovery algorithm which tries to correct over-erased bit cells in flash bank. This step doesn't change the contents of flash.

Pre-condition:- Pre-condition is the one which clears the flash bit cells to 0. Now, unlike precompaction, precondition doesn't work on all the flash sectors unless user wishes to erase all the sectors. It just works on sectors which user tries to erase.

Regards,

Manoj

Hi Manoj,

Thank you for your reply.  

It seems like i got mixed up on pre-compaction, but to be honest, i have no clear idea of what that means.  But my question is how do you explain if the device is lock up (password is accidentally set wrong) when i erase only sector J & I and password is stored in sector A.  I see your statement of sector J and sector A are balanced for read operation but i see no connection on this balance statement for read that can explain the wrong password values by accident.

Maybe another way for me to ask you a question:

1- if i just erase sector I and some thing happens (like a watchdog reset or power disruption) during earse, will the CSM password accidentally change to random value?  The sector I maybe bad, but i can afford that because we can still connect and got the status info out of DSP from different sector.  What i am avoiding is the DSP device completely locked out because of password.  can you please confirm this by codes?  I have had 2 DSP devices locked up already so i will not experiment this unless it is truly this way.

Thanks. 

Henry

Henry,

A CPU reset (or) power down when you are trying to erase Sector J can potentially lock the device for the reasons I have explained in my previous post. However, the possibility of accidentally locking the device is extremely rare. Infact, we have never seen this happen in TI factory testing.

If you don't want a situation of accidentally locking a device, you could choose any sectors other than Sector J (or) A for repeatedly updating system related information into flash. Generally, I have seen customers storing calibration data in specific sector. So, I would suggest you to use any Sector  B,C,D,E,F,G,H,(or) I

Regards,

Manoj

Hi Manoj,

I am not sure how you do the factory testing.  But try write 1 to the WDOVERRIDE bit and NOT reassigned WD watchdog output to its interrupt.  Then, kick start the WD and try erase function repeatedly, you will run into this issue.  

Now what i said above is just a way to illustrate how easy to cause your device to lock up and no one will do that in functional code.  Flash API V2.10 disable WD before erase / program called but doing the purposely wrong stuffs above will not disable WD even API disable it.  Believe me, i can to it twice already by different ways.

I can certainly and easily choose a different sector.  But i would like to have an assurance  that this will not happen again and i don't want to try that as well because it is painful to replace the part.  I don't have the socket Eval board nor socket proprietary board.  Can you please help me with that?

Thanks,

Henry

Henry,

Do you have any example code which can be used to re-produce the issue?

Regards,
Manoj

Hi Manoj,

Thanks for your help. I should be able to get you the small sample codes.
Note:
I have a big code that include this erase/program functions and it is initiated / responded from / to the emulator board which is triggered from the PC. This causes the triggering of erase/program to be async to the WD counter operation.

I can parse it down to a small sample codes and put some sort of pseudo random delay to start erase/program so that i can mimic the async nature of my emulator initiation from PC to WD counter expiration time frame.

Please wait.

Thanks,
Henry

Hi Manoj,

Sorry, i have been busy on other tasks last few days.

Finally today i have a chance to parse it down and give you this example.

Can you please let me know your email address so that i can send you the CCS project plus the note as well?

Best Regards,

Henry

Henry,

Please post the example code in this forum. It shall be useful for others with similar concerns / questions.

Regards,

Manoj

Hi Manoj,

There's used to be an attachment symbol which user can just click on it, but i don't see it now. 

Only see Insert/Edit Media and when i upload Zipx file to it, it complained that the file extension is not the right type.

I can send it directly to you via mail and you can find a way to post it on this forum.

Note: 

1- To change from sector J to sector I, you need to do the following:

       a- in EEPROM_Erase() function, change SECTORJ to SECTORI).  This function returns Status, so do not uncomment this line: // Status1 = Flash_Erase((SECTORI),&FlashStatus);

       b- In F281x_EEPROM.h file under DSP281x_EEPROM directory, change START_OF_SECTOR to starting address of sector I.

           #define START_OF_SECTOR  0x3D9E00  // Sector J to I //

2- I have tested to make sure that the erase / program works correctly for this small test case.  However, i did not turn on the bit to lock down the WD.  You need to write 1 to the SysCtrlRegs.SCSR[0] in the main_slave_FPGA.c to do this.  

EALLOW;
SysCtrlRegs.SCSR = 0x0000;
// NEVER WRITE bit SCSR[0] = 1
// if planning to use flash API. what happens is that when flash API
// function is called, the API will write to WDDIS to disable the WD
// if SCSR[0] is cleared by writing 1 to it earlier, the WD can not be
// disabled.
// Ensure to re-enable WD after each API call completes.

EDIS;

3- I have some pseudo random delay and i tested it and it seems to insert random delay as well.  However, since i did not write 1 to SCSR[0], i don't know if these random delay will cause reset and lock out the password at the right time.  You may want to tune it a bit.

4- I can tell you that when i tested this code, i had it failed and locked up password on my twice by the following way:

    a- Without writing 1 to SCSR[0], i randomly hit the break point when the erase or program is active on sector J.

    b- Writing 1 to SCSR[0], i randomly issue function from PC emulator to erase or program the sector J.

So, these two incidents that i have cause sector A to have some random password even through i am erasing / programming sector J.

Please give it a try to see if you can lock up the device first, then, move to sector I only and see if you can avoid it.

Thanks,

Henry Nguyen

Henry,

In Pg 62: TMS320x281x System Control and Interrupts Reference Guide (Rev. G). It clearly specifies that if WDOVERRIDE bit is cleared by writing '1' to it, it enables watchdog if currently enabled.  This explains why your device is getting watchdog reset in the middle of flash erase / program.

We have clearly cautioned users that you shouldn't do this in Flash281x_API_V210.pdf (Flash API document)

Regards,

Manoj

Hi Manoj,

I know this and I already mentioned that this bit should not be written 1 to clear in functional mode.

Reset can happens in many ways: WD, power glitches, etc.

The original question is why password (in Sector A) got messed up if Sector J is cleared and "reset" happens.
You came back with an explanation that there is a "read balance" thing between sector A and J and to be honest, i have no idea how to understand that.

OK, so my point is to demonstrate that if i move to sector I and a reset happens (say power supply glitch when the device is running in its application), then my device should not get locked up. ==>>>> Lock up is my concern, not reset.

To cause reset to happen, you can temporarily write 1 to this bit to force WD always running and erasing / programming sector J in parallel.

Hopefully you can run into device lock up because reset is happening while erasing / programming on sector J.

Then, you can put in new device and change the EEPROM starting point to Sector I and rerun the codes again.

The point here is to prove "your" theory that if we erasing sector I and reset happens, then, the device SHOULD NOT lock up.

I have forwarded the CCS project to Greg Sheridan and he said that he would forward it to you.

Please let me know if we need to have a phone discussion on this issue.

Thanks,
Henry

Hi Manoj,

Has Greg Sheridan provided to you the example code project which i sent to Greg?

Please let me know if you are able to get the lock up and changing the sector will avoid it?

Thanks,

Henry

Henry,

Yes, I did get your code from Greg.

I ran your code by changing SCSR.WDOVERRIDE = 1, with sector J erasing at random instances as you had configured the code. Eventhough, theoretically possible, interrupting flash erase operation of sector J didn't seem lock the device as you mentioned. At some random instances, it did enter Illegal ISR at which point flash looked locked. But, when I applied a debugger reset, the device was unlocked.

I believe a sporadic watchdog reset possibly gets the flash state machine in a random state making it appear as a locked device. As I said earlier, I would recommend you to use Sector I if you want to be sure that the device doesn't get accidentally locked.

Regards,

Manoj

Hi Manoj,

Ok thanks for the try.  When you said debugger reset, you meant the jtag ntrst reset or something else that you tried?

Can you please confirm if you can reconnect and "re-download" the DSP codes again?

i wish i should have captured that ccs console message.  

Clarification from my side:

I tried to reconnect and it seems to connect back, but when i started to download codes again, this is when it said device is locked.  i can not erase it from CCS at all.  So, it seems like a real locked up.

it happened to me twice.  

Now, if i powered cycle the device again, it ran fine as I said in my first email. 

So, i would like to confirm if you were able to download the code again and then run after that or you just power cycle and it ran again?

maybe WD reset does not hit correctly at the right time since the delay time is pseudo random.  

Thanks,

Henry

Henry,

Debugger reset is essentially a CPU reset using CCS. In CCS5v debug perspective, you need to choose Run->Reset--> CPU Reset.

Yes, I was able to reconnect and re-download the DSP code again without any problems. I ran your code over multiple iterations and didn't see any problem.

Regards,
Manoj