Verify Flash Failure

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've run into an issue loading a binary into flash on a SAMG55.  I keep seeing this exact error pop up, but it's not something that always happens, as it depends on the final compiled code (i.e. recompiling with changes sometimes makes it go away).  I've also attempted to load a problematic binary into a second board, and have the same result, so it's not a damaged byte in the flash memory.  I'm stumped on this one.  My current work around is to not verify the flash when programming, but it's not a final solution, and I'd really like to know why this is happening.

 

Any insights on this issue?

 

Last Edited: Thu. Sep 7, 2017 - 09:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What tool are you using?

 

Do you have another way to check what has actually been written to the flash?

 

There was a bug a few years ago that caused read corruption with J-Link (and Atmel things based on J-Link) - so are you all up-to-date with tool versions ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using an Atmel-Ice, FW version 1.26.  I can try a write without verify, then read it back and compare files.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does read that byte back as 0x5E.  The hex file used to program isn't the same format st the one produced with a read, so it's not easy to do a quick compare of everything, but I found that area and manually checked. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One more bit of info: I added some code to my project and recompiled.  I get the same error (0x5F reading as 0x5E) , but in a different memory location now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not familiar with SAM's, so may be a dumb question, but can you use a slower programming speed?  

if so, does that change the results?

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can.  I dropped it from the default 7.5MHz to sub 1MHz, and no change.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hillridge wrote:
It does read that byte back as 0x5E. 

But what is actually programmed in the Flash?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh I see what you mean.  Is there a way to check this beyond having the program itself read that location?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need something that's independent of the Atmel-Ice

 

Do you have a SAM G55 Xplained Pro Evaluation Kit?

http://www.atmel.com/tools/atsam...

 

Or some other brand of JTAG probe?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do have an xplained.  Are you suggesting checking via the edbg interface?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just did the following:

Programmed an Xplained board via SWD using the Atmel-ICE tool.  Verify was left unchecked due to the error I am having.

I disconnected the Atmel-Ice tool and connected the board via EDBG.

I then did a verify using the same file, and got the same mismatch error.

Finally, I reprogrammed using EDBG and got the same mismatch error.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there anything else sharing the programming pins?

if so, are they properly not selected while MPU is being programmed? CS pins pulled up/down as needed.

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the Xplained I believe they are shared with the EDBG chip, but on my board they are dedicated to a JTAG port.  100K pull ups on TMS, TCK, TDI.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Silly question:  You >>are<< doing an erase before sending the "new" firmware?

 

Hillridge wrote:
Is there a way to check this beyond having the program itself read that location?

In the [pretty rare] cases such as yours, I use my programming setup to "Read flash", and then edit and examine.  And/or, use the related tools to write both sets of .HEX in the same format, and then use a difference utility.

 

What results do you get if you create a new/trivial "Hello world" sanity-check program?  Does that program and verify?  When you then read out flash, are all the rest of the locations erased?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your using a ribbon cable with IDC connector, some times these will develop a broken wire at the point where the cable enters the IDC.

These broken wire(s) can cause "flakey" things to happen, but the fix is easy.   Carefully pry the cap off the IDC connector, move it down the cable a 1/2 inch,

and re-crimp, cut off the excess cable.    Should be like new again! 

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Atmel-Ice is only a week old, plus I see the same error when programming over EDBG via a USB cable, so that rules out the programmer itself.

 

It's also super consistent.  I will get the verify error every single time I try and load a binary that causes this error.  It's only inconsistent in that changes to the project that produce a new binary may make the issue go away, or may just move it to a new memory location.  Super weird.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I let this drop for a few weeks since I could work around it, and things got super busy.  I'd now like to get to the bottom of it, as not being able to verify that code was programmed correctly is no bueno.  

 

Assuming we can't suss this here, what's the best way to get in touch with an FAE or someone else directly affiliated with Atmel/Microchip?  

 

I am 100% sure this is not a hardware issue, or at least not a hardware issue specific to one particular physical instance of the SAMG55 or AtmelICE programmer.

 

It almost seems like the erroneous value is changed after programming but before verify, though how this happens, I do not know.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Bumping with new information.

I found that this error does not occur when the flash is programmed without first erasing it.  Still scratching my head on this beyond that.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Problem : Unable to flash the bin/hex file to production board and able to flash the program on Development board.No hard ware issue.

 

We  are using Atmel ICE for production(SAMG55J19) and development board SAMG55 X PLAINED PRO and same Hardware.

 

Please check below observations and provide the quick solution.

 

Development board 

 

If the GPNVM 0 or 1 code is not working on Development board,By default GPNVM Value is 2 ( Code is working in this mode) .We need to use hardware chip ease( Software chip erase not working)

 

Production Board :

We are unable to set boot mode for production.Code is working this mode Only as per below data sheet.

 

Inline image 1

 

SAMG55 X PLAINED Development Kit .

 

Inline image 4

 

 Production board (Unable to set GPNVM Bits : Boot modes )

 

Inline image 2

 

Inline image 3

 

Flash verification failed on production board ( ASF 7.0)

 

Inline image 1

 

J link Error -5 (Unable  flash the bin/hex )

 

Inline image 2

 

IDE firmware Update ERROR 

 

 

 

Q1: Flash verification Error on ASF IDE and J-Link ( Error  -5 )

       Can you provide details about Error  code details and -5 significance ?

 

Q2: Set the GPNVM bit to boot from the flash. We don't not have hardware chip erase on production board.

       (SAMG55 X PLAINED PRO Development board we are using hardware chip erase .Not working for GPNVM 0 or 1 )

 

Q3: We are using SWD schematic from reference design. ( SWD CLOCK and Data Lines are OK)

 

Q4 : How to check the boot loader firmware for Atmel SAMG55J19  ( We are using Atmel Studio 7.0 on windows 7) 

        Is there any way to find boot loader version on production and development broad SAMG55 X PLAINED PRO .
 
Q5 How to update the Firmware for SAM ICE  and Current version is 1.26 and latest is 1.36 .
       I found some information on below link ,But unable to update the ICE firmware.
 

 

Please provide  valuable feed back and inputs .

 

 

Srinivas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hillridge wrote:

I found that this error does not occur when the flash is programmed without first erasing it.

 

Thank you Hillridge! We had the same issue with a SAME70 XPLND board. It can happen at different addresses in function of resulted elf binary: sometimes disappears, actually most of the time works, for us it appears very seldom. Today when appeared again, we tried the same elf on 2 different computers (Win10 and Win7) with two different SAME70 XPLND boards. It was the same error location with same values: "Verifying Flash...Failed! address=0x4060c7 expected=0x7f actual=0x7b".

Then I did find this explanation, and can confirm that doing separate erase, followed few seconds later by separate program+verify removes the problem (verify succeeds!), so can be some Atmel tools bug?

 

Daniel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I actually haven't tried to do an erase then a program+verify.  I simply wasn't erasing at all!

I'll have to try it as two steps like that and see if it works for me as well.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can confirm the same as DaPa1. Using Atmel Studio 7.0.1645 with an Atmel ICE (firmware 1.27) and an Adafruit Metro M4 Express board (ATSAMD51J19A). I would sometimes get "Verifying Flash...Failed!" errors that didn't seem to be related to bad hardware, but rather seemed somehow related to changes in my program code. For a particular version of my code, I would *always* get the same error at the same address with the same values. A minor change in my code would often make the verify error disappear. Then after more code changes, it would reappear somewhere else.

 

This feels like a bug in Atmel Studio 7, or somewhere else in the Atmel toolchain.

 

I found two work-arounds:

 

1. First manually erase the chip ("Erase Now" button), then program the chip with "erase flash before programming" box unchecked.

2. Program the .hex file to the chip, instead of the .elf file. But each time you reopen the Device Programming dialog, it defaults back to .elf.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot to respond earlier, but I can also confirm #1 works. 

That's interesting that the hex file doesn't have the same problem as the elf though. 

 

Something else I noticed while trying to figure out what's going on, is that the issue always seems to happen around the same code area, namely the .fini_array. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hillridge wrote:

It almost seems like the erroneous value is changed after programming but before verify, though how this happens, I do not know.

 

Yeah, I think you may be right. Maybe it programs the flash memory using the text+data section from the .elf, but then it also improperly overwrites part of the same flash memory with some other section from the .elf, before it performs the verify step. That might explain why programming the .hex instead of the .elf works fine (at least in my limited testing). Although it's not obvious why doing a manual erase would make a difference.