Verify Flash Failure

Log in or register to post comments
Go To Last Post
25 posts / 0 new
Author
Message
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
#1
Posted by Hillridge: Thu. Sep 7, 2017 - 05:11 PM
  • 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?

 

Tags:

Tools, Compilers, Assemblers, Linkers and General Programming (ARM-related)
Last Edited: Thu. Sep 7, 2017 - 09:56 PM
Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22564 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Thu. Sep 7, 2017 - 05:15 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 oscillator: https://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...
Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 05:22 PM (Reply to #2)
  • 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.

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 05:30 PM (Reply to #3)
  • 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. 

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 05:56 PM (Reply to #4)
  • 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.

Top
ki0bk
ki0bk's picture
Level: Raving Lunatic
Joined: Mon. Sep 8, 2014
Posts: 8859 View posts
Location: Over the rainbow
Posted by ki0bk: Thu. Sep 7, 2017 - 06:14 PM
  • 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

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 06:19 PM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22564 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Thu. Sep 7, 2017 - 06:58 PM (Reply to #4)
  • 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 oscillator: https://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...
Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 07:03 PM (Reply to #8)
  • 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?

 

 

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22564 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Thu. Sep 7, 2017 - 07:09 PM
  • 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 oscillator: https://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...
Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 07:36 PM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 07:49 PM (Reply to #11)
  • 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.  

Top
ki0bk
ki0bk's picture
Level: Raving Lunatic
Joined: Mon. Sep 8, 2014
Posts: 8859 View posts
Location: Over the rainbow
Posted by ki0bk: Thu. Sep 7, 2017 - 07:49 PM
  • 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

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 07:56 PM (Reply to #13)
  • 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.

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40131 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Sep 7, 2017 - 08:06 PM
  • 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.

Top
ki0bk
ki0bk's picture
Level: Raving Lunatic
Joined: Mon. Sep 8, 2014
Posts: 8859 View posts
Location: Over the rainbow
Posted by ki0bk: Thu. Sep 7, 2017 - 08:06 PM
  • 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

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Thu. Sep 7, 2017 - 11:22 PM (Reply to #16)
  • 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.

 

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Mon. Oct 2, 2017 - 03:27 PM
  • 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.

 

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Tue. Oct 24, 2017 - 07:05 PM
  • 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.

 

 

Top
kakarla_sreenu
kakarla_sreenu's picture
Level: New Member
Joined: Fri. Mar 31, 2017
Posts: 6 View posts
Posted by kakarla_sreenu: Fri. Nov 3, 2017 - 06:08 AM
  • 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

Top
DaPa1
DaPa1's picture
Level: New Member
Joined: Tue. Feb 13, 2018
Posts: 8 View posts
Posted by DaPa1: Tue. Feb 13, 2018 - 12:26 PM
  • 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

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Wed. Feb 21, 2018 - 08:39 PM
  • 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.

 

Top
schamberlin
schamberlin's picture
Level: New Member
Joined: Wed. Apr 25, 2018
Posts: 5 View posts
Posted by schamberlin: Thu. Jun 14, 2018 - 10:09 PM
  • 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.

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 169 View posts
Posted by Hillridge: Fri. Jun 15, 2018 - 02:50 AM
  • 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. 

 

Top
schamberlin
schamberlin's picture
Level: New Member
Joined: Wed. Apr 25, 2018
Posts: 5 View posts
Posted by schamberlin: Fri. Jun 15, 2018 - 03:48 PM (Reply to #18)
  • 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.

Top