Verify Flash Failure

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

 

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

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