Error log from PSoC programmer Program Finished at 19:02:29 | | FAILED! Verification failed on 0 row. | Verifying of Flash Starting... | Programming of Flash Succeeded... | Programming of Flash Starting... | Erase Succeeded | Silicon: 0E49, Family: 9E, Major/Minor Rev: AI Program Requested at 19:02:11 | Successfully Connected to MiniProg3/1519DD0008C4 at 19:02:08 | MiniProg3 version 2.05 [3.08/2.08] Opening Port at 19:02:07 | Device set to CYBLE-014008-00 at 19:02:06 | 131072 FLASH bytes Device Family set to CY8C4xxx-BLE at 19:02:06 | Active HEX file set at 19:02:06 | C:\...\CortexM0\ARM_GCC_493\Debug\aquaspace.hex | | Users must be aware that the following PSoC device should not be powered or programmed at 5V. Doing so will cause damage to the device: CYRF89xxx Session Started at 19:02:06 | PPCOM Version 22.0
Usually when a bit fails in flash, it is a hardware endurance failure for the flash cells themselves. Sounds like you hit the maximum write cycles for the flash. (Or the flash got damaged in some other way)
This normally only occurs after some x number of flash erase/write cycles. (10k cycles iirc?). It doesn't have to do with interrupting the power/programming sequence I believe. Supplying higher voltage than the chip needs might also cause this, but I don't know from experience.
I don't think I would hit the maximum number of cycles(hardly 100 cycles). I supply 5volts regulate one.
Hmmmm. That is definitely odd then; Yeah, looking up the datasheet it does say 5.5 volts is ok.
Some things to try: Unplug the programmer and it's USB cable, power/unplug the chip, then reconnect it all. (Probably won't do anything, but worth a shot)
Try changing the HEX code at the error location to be different (or the same), and see if that affects the results. (Setting it the same will probably pass, but limits code allocation. Setting it to a different value should check if other bits/values are still bad, or if it is just the specific instruction)
It does seem like the flash chip is damaged, and thus if you don't need the chip anymore, it might be faster/easier to just switch to a new hardware chip.
Thank you very much Pratt for your inputs.
I did try all the setup changes as you suggested but nothing wroked out :(.
I would like to try the HEX file stuff and that is interesting to see what's happening.
>> It does seem like the flash chip is damaged, and thus if you don't need the chip anymore, it might be faster/easier to just switch to a new hardware chip
As of now I'm using my other customized prototype board but I would like to fully understand what caused the flash damage like power or handling of chip etc.
I don't want to end up production boards in the field failing with this issue.
Did anybody else faced this type of issue? Can Cypress digits/hardware team give some inputs
changing hex file gives me checksum failure
Bummer, not as easy to poke the bits as I thought :(
The idea essentially, is to get the programmer to program a different value at the location that is failing however, so changing your code to something that will compile into a different value at that location should be enough to test.