1 2 Previous Next 27 Replies Latest reply on Nov 30, 2012 9:27 AM by rajivv_36

    Flimsy Flash CY8C21434

       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

        • 1. Re: Flimsy Flash CY8C21434





          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?







          • 2. Re: Flimsy Flash CY8C21434

             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.

            • 3. Re: Flimsy Flash CY8C21434

              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.

              • 4. Re: Flimsy Flash CY8C21434

                Some references for connection and read -








                and attached.




                Regards, Dana.

                • 5. Re: Flimsy Flash CY8C21434

                   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. 

                  • 6. Re: Flimsy Flash CY8C21434

                    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.





                    • 7. Re: Flimsy Flash CY8C21434

                      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.

                      • 8. Re: Flimsy Flash CY8C21434

                        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.




                        Regards, Dana.

                        • 9. Re: Flimsy Flash CY8C21434

                           @ 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

                          • 10. Re: Flimsy Flash CY8C21434

                            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.





                            • 11. Re: Flimsy Flash CY8C21434





                              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.

                              • 12. Re: Flimsy Flash CY8C21434

                                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.

                                • 13. Re: Flimsy Flash CY8C21434

                                  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 -




                         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.

                                  • 14. Re: Flimsy Flash CY8C21434



                                    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).

                                    1 2 Previous Next