Verify Flash Failure

Go To Last Post
18 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 ... ?

  • 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

 

  • 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?

  • 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?

  • 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

 

  • 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

 

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