- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I get Verification failed on row 0 error on CYBLE-014008-00. This used work for at-least 50 times before I started seeing this error.
I think the one of the flash row is damaged and can't recover. Tried erasing and programming several times to recover but in vain.
Tried using Sflash tool which comes with PSoC Creator and below is the error I see:
"RowId = 0 Failed!Verification failed at address 0x0FFFF200. Expected data = 0xCDCCCBCF, read data = 0xCDCCCB8F"
From this I see bit 6 at address 0x0FFFF200 is culprit. I think the erase operation is failing at this bit.
It would be great help to know why this occurred or when it can occur(power failure during erase or programming operation).
Appreciate your early response.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't think I would hit the maximum number of cycles(hardly 100 cycles). I supply 5volts regulate one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
changing hex file gives me checksum failure
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.