Flimsy Flash CY8C21434

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 Dear Sirs, I'm trying to solve a problem on a capacitive keyboard that is quite odd. 

   

Sometimes the capacitive keyboard is stuck and doesn't works no more; just a re-programmation of the mcu CY8C21434 solves the block of the capacitive keyboard. We obtain the block just doing some voltage dips on the main supply.

   

On different boards  after 230V interruption  the flash of the microcontroller is completely zeroed (every single byte is 0x00) and in some rare cases the flash mem is just corrupted (checksum different from hex).

   

No writing to flash are done in the firmware.

   

In the first firmware there was no watchdog and no LVD enabled moreover there was the CPU_Clock setted to work @ SYSCLK/1 but the supply voltage was 3.3V and this is not allowed (datasheet page 19/50) because the oscillator operates outside the valid operation region (yes the cpu in most cases works also outside VOR).

   

With a new FW with WDG, LVD enabled and SYSCLK/4 (so now working inside the VOR) all seems to work correctly and there are no blocks. 

   

Now If i can accept a flash corruption (there is acompressor near the board)  I can't explain ho can all the flash to be erased.

   

Can someone tell me how the mcu can be completely erased

   

Best regards and many thanx to anyone will help

0 Likes
27 Replies
ArvindK_86
Employee
Employee
10 sign-ins 5 sign-ins 10 solutions authored

 Hello,

   

 

   

Can you please clarify as to what you mean by 230V interruption? Please avoid conditions that push the device beyond it's electrical limits, as doing this might permanently damage it or cause unstable behavior.

   

 

   

Flash writes are temperature dependant to ensure proper operation/lifetime. Please have a look at your device's Technical Reference Manual and http://www.cypress.com/?rID=2849 for more information.

   

 

   

Is there any chance you are writing to the VLT_CR register manually?

   

 

   

Regards,

   

Arvind

0 Likes
Anonymous
Not applicable

 Thank you for your quick answer, I'll try to be more clear. 

   

We have a dip generator (Pacific Smartsource 105-AMX) that allow us to create dips on the 230Vac main supply. 

   

A winding transformer transforms the 230Vac into 12Vac then a bridge let us to generate 12V and with a linear ldo regulator we obtain 3.3V that give the power supply for the cypress mcu.

   

I think that variations in the 3.3V (caused to 230V dips) cause malfunction of the cypress mcu (because of lackness of WDG and LVD enabling in the old firmware) but I can't explain fully flash reset.

   

Moreover, as I previously wrote, we doesn't use function that writes to flash memory of the cpu.

   
        
0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I am not aware of any HW state machine in PSOC 1 that will erase the entire flash, so I am

   

suspicious that when you are reading the part back out it is not powered up or Miniprog pin

   

terminated correctly for the programmer to read ?

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Some references for connection and read -

   

 

   

http://www.cypress.com/?docID=32022

   

 

   

and attached.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dear Dana, I'm using Psoc MiniProg as you correctly stated and I'm sure that the programmer works perfectly and is connected perfectly. I can program part and read hex file without no problems (I compare checksum, read flash, verify ecc). My programmer works perfectly! 

   

If i take a board with corrupted flash (before it was working)  and I look at I2C-bus pin of the CY8C21434 the mcu don't give any ACK to master queries because of has no worjing program inside. 

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Any stresses to a chip outside of "Maximum Ratings" will have literally "unpredictable effects". Even the programming of flash is thinkable, but quite unprobable, although there IS a piece of code inside the PSoC that is able to program flasch or security fuses.

   

The fact "Chip does not run anymore" has not mandantorily be the cause of lost flash contents, I would rather suggest destroyed pin-drivers.

   

To leave the suspections, what you can do is measure, Find yourself a scope and watch the power-supply of your board, have a look at all pins and check whether you have got a stable 3.3V, no negative spikes on input etc.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Bob has a point, huge transients could erase all flash, all I can say is

   

experience just partial corruption of memory is more typical. The fact

   

all memory is erased, down to all bits, still makes me suspicious of

   

the interface on the read ? Given you had an operating device prior

   

to failure evaluation.

   

 

   

Keep in mind basic physics of flash programming is enough field

   

strength to force charge thru an oxide layer. Large transients can do

   

this, but also accompanied by lots of gate oxide shorts. What is the current

   

drain of a failed part fully erased ?

   

 

   

Otherwise I am stumped.

   

 

   

Regards., Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

One other comment on Bob's suggestion. Using a DSO you can set it up

   

for a truly diverse set of logical trigger combinations, level, state.......you name

   

it.

   

 

   

So set up code with an "I am alive pulse" on a pin, use that in combination with something

   

that indicates failure, V,I,T, State, and capture a record of the environment. Detective work.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 @ BOB & Dana

   

 

   

Dear Bob, we verified that the chip loses flash content in most cases (every byte = 0x00, checksum 0x0000) and in some cases it is just corrupted (checksum different from original after voltage dips). 

   

After flash is corrupted or flash is erased we program the same board with the same firmware and after that the board works correctly. I'll check 3.3V with dips and I'll let you know. 

   

Could you tell me in which cases the mcu could execute autonomously a flash re-programmation ? For example,  what could happen if the mcu jumps to an incorrect istruction?

   

In two board on four I'm testing, the flash erase happens everytime I create more than 10 voltage dips in a sec.

   

Just to let you know yesterday I connected a surge generator to a coil and I stimulated it with also 4.4kV putting the coil near the mcu and no flash erase or corruption occurred (just tried in the past with burst and surge on main AC 230V); the same experiment was done with the board inserted between earth plane and a phase (stimulated in surge mode with 4.4kV) connected on a 1m^2 square aluminium sheet with the same result. After that I tried with a VCP (vertical coupling plane) near the board that was stimulated with 16kV air discharge and also in that case no no flash erase or corruption occurred. 

   

Other experiments makes me think that this corruption is not imputable to conducted or irradiated disturbance on the board but to short voltage dips (< 0.1 sec)

   

 

   

@Dana

   

Today I'll try to measure VDD current (If my understanding is correct) on a fully erased part and I'll let you know

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

It is hard to believe, but the PSoCs have got something like a pre-programmed  "System" on them that are performing very basic functions. One of these is programming flash memory. So when you manage to call this (repeatedly) you may erase all your flash.

   

Much easier would be to just program the relatively small area containing the security bits which when programed will inhibit the read-out of flash memory with a programmer thus showing your 0x00 readings.

   

10 brownouts per second would be a hard thing to manage and I wold check thoroughly if at ANY time during those voltage "dips" ANY input to the PSoC is asserted a voltage greater than the current Vdd or smaller than Vss.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 Hi,

   

 

   

The exact same thing happened to me a while ago. My chip was just no longer working. I reprogrammed it and it start working again. As MAtusel said sometime with 0x00 and sometimes the chip having a corrupted checksum. 

   

 

   

After some investigation, I discorvered taht my problem was caused by ESD poorly handle in my board.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I'm partially relieved in reading EricS' post but I'm still doubtful that the new fw I have created can solve al my problem (watchdog, lvd and sysclk/4 implemented and now the board survive to voltage dips) so I'm still waiting for other people to help. 

   

If it can be useful, here attached there is the supply voltage shape when a flash fault occur.

   
        
0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Maybe I am getting anal here, but I am still hung up on a transient causing all

   

FLASH to be erased. The low level SROM functions can erase blocks, but block

   

address has to be provided. So the transient woulk have to be capble of a series

   

of calls providing the sub calls to load a block address then erase.The only function

   

call that could erase all seems to be only via an external programmer. From the tech

   

manual -

   

 

   

3.1.2.7 EraseAll Function

   


The EraseAll function performs a series of steps that
destroys the user data in the Flash banks and resets the
protection block in each Flash bank to all zeros (the unpro-
tected state). This function may only be executed by an
external programmer. If EraseAll is executed from code, the
M8C will HALT without touching the Flash or protections.

   

 

   

Is it possible the read back function in programmer has a bug ?

   

 

   

The question I had about Idd of a fully erased part, is the thought if

   

a transient was large enough to erase all flash, then probably a lot of onchip

   

shorts would be created, which would be relfected in power supply current. Of

   

course a transient could hose the flash sense amps, and make it look like flash

   

was erased, on a part that has been erased might be instructive to do a readback

   

right after programming. Although one might think sense amp was instrumnetal in

   

both programming and read.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 @Dana  

   

A fault board has VDD current consumption of cypress near 2750uA against the 8mA of a working board. 

   

After the fault i took the board, I removed the ferrite that is in series in the track to vdd and I measured the current consumption with a fluke 185 multimeter, then I restored the ferrite and I checked the checksum that was 0x0000 (flash erased case).

0 Likes
Rolf_Nooteboom
Level 5
Level 5
10 sign-ins 5 solutions authored First solution authored

 Very interesting topic!

   

 

   

I've had spurious flash erases at voltage drops also. For me the solution was to change the VLT_CR register setting to a higher value (trip voltage).

   

 

   

This problem seems to hit some products once in a while, even if no flash writes are implemented in firmware (see PSoCdeveloper). I tend to think the M8C core will lose track at the power glitches and performs some unwanted SROM functions. Therefor, changing the trip voltage will affect this behaviour.

   

 

   

I think it might be a good idea to open a technical support case and let the people at Cypress have a look of what is wrong. And please report back what the outcome will be, I am curious too.

   

 

   

Regards,

   

Rolf

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I too recommend a tech case be filed. It could be there is a production

   

programming capability in the part that does effectively a bulk erase

   

and we are just not aware of it. A special production test mode........

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Thanx to everyone for your support. I have already open a technical case and Cypress tecnicians replied quickly. Now they are analizing the firmware and the hardware, I think that at the end of the story, if they want to deepen the matter, I'll send them a board with this consistent problem of flash erase.

0 Likes
Anonymous
Not applicable

 In my project i found this regarding VLT_CR register:

   

"The writes to the VLT_CR register below include setting the POR to VLT_CR_POR_HIGH, VLT_CR_POR_MID or VLT_CR_POR_LOW. Correctly setting this value is critical to the proper operation of the PSoC. The POR protects the M8C from mis-executing when Vdd falls low. These values should not be changed from the settings here. Failure to follow this instruction could lead to corruption of PSoC flash".

   

In the faulty boards the original fw has no Trip Voltage enabled and was setted to 4.81 (5.00V) SO...now I have enabled in the "faulty" firmware just the Trip Voltage [LVD(SMP)] =3.02V (3.10)V with this istructions:

   

M8C_EnableIntMask(INT_MSK0, INT_MSK0_VOLTAGE_MONITOR);

   

M8C_EnableGInt;

   

(no WDG or CPU_Clock = sysclk/4) 

   

 

   

AFTER THAT MCU'S FLASH DOESN'T ERASE ITSELF ANYMORE. 

   

At the moment the problem seems to be solved (the board with LVD enabled is now running correctly by two hour also with power supply voltage drops) just with this modify (LVD trip voltage).

   

After a phone conversation with a cypressFAE my rough explanation could be this: with the original fw the mcu started at a wrong voltage and the interrupt INT_MSK0_VOLTAGE_MONITOR wasn't catched because it wasn't enabled by previous istruction (and by correct setting of LVD); in that case the mcu mis-execute some istruction and corrupt flash....

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

WOW!

   

As I can see now, we have to read still more in the manuals!

   

For my understanding:; You did set the Power setting to 3.3V / 24 or 6 MHz and the trip-voltage was still at the 5V level.

   

 

   

In my opinion this is a mis-setting that should AT LEAST give a warning when building the project. You ought to place a new thread in the PSoC1 software-forum with a link to this thread so that Cypress can address this errorneous behaveour and can correct that.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 Maybe I should have been less enthusiastic. The board failed the test 20 minutes ago, all flash memory has been erased also with LVD enabled (checksum 0x000).

   
        
0 Likes
Anonymous
Not applicable

 It reminds me that we have some failure of a project using the PSOC1 and the problems seems to have the flash erased. We suspected  it was due to some kinds of power glitch or some voltage spike on VCC and made some changes to the power supply circuit and layour which seems to improve but not 100%. We still has some return once a while but didn't have time to do more test /investigation,  Hope you can find the root cause of this problem

0 Likes
Rolf_Nooteboom
Level 5
Level 5
10 sign-ins 5 solutions authored First solution authored

In fact, PD shouldn't be enable to produce wrong power / trip / speed settings. Also the power-up / down ramp and settings are more critical than it should be.

   

 

   

It's obvious M8C is executing SROM functions where it shouldn't.

   

 

   

One thing for sure is: you're not the only one experiencing this, the downside is that there's no real guideline as far as I know on how to circumvent this.

   

 

   

Regards,

   

Rolf

0 Likes
Anonymous
Not applicable

This thread is rather old, but I want to know if Matusel received an answer from cypress concerning this problem. Cause I'm having this problem on some of my boards and I did not succed to fix it for now. 

   

 

   

As Rolf stated there is no fix known. So I want to know if Cypress came out with a solution like better filtering for the chip supply or anything else.

0 Likes
Anonymous
Not applicable

What is the flash security settings set in the project? Though this doesn't explain the problem; but can rule out possibility of SROM functions being behind this problem. If the flash blocks are write protected, then SROM functions cannot write into flash.

0 Likes
Anonymous
Not applicable

Hello to all, even if I set the write protection I happened to have blocks of flash deleted (0x00). At the moment I'm trying an external reset chip and see if I can eliminare the problem of flash corrupted. Regards.

0 Likes
Anonymous
Not applicable

I am curious. Was this issue ever resolved? I am seeing a similar issue in returned products.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

This thread is so old, consider posting a CASE, and then update this

   

thread for the community. In the CASE post a link to this thread.

   

 

   

    

   

          

   

To file a tech case -

   

 

   

www.cypress.com

   

“Support”

   

“Technical Support”

   

“Create a MyCase”

   

 

   

Regards, Dana

0 Likes