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?
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.
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 ?
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.
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 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.
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
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.
@ 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)
Today I'll try to measure VDD current (If my understanding is correct) on a fully erased part and I'll let you know
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.
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.
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.
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
220.127.116.11 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.
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).