Programmed Board Won't Work Until After a Debug Session

Log in or register to post comments
Go To Last Post
5 posts / 0 new
Author
Message
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 172 View posts
#1
Posted by Hillridge: Tue. Sep 25, 2018 - 03:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a bit of a head scratcher here.  I'm using a SAMG55 on a custom board and programming it with an Atmel-ICE programmer.  The board will program and verify fine, according to Atmel Studio, but so far as I can tell the code will not actually run until I start a debug session on the chip.  Once I have done that and halted the session, it will program and run normally.  I only have to do this once, and it's impossible to re-create the issue once I have done it, so I have limited chances to figure out what is going on. 

 

Has anyone run into this issue?  What is the debug session initializing that the normal programming routine isn't?

 

It's not much more than a curiosity now, but I have a feeling it will be a headache once I move out of development and into production.   

Tags:

Tools, In-System Debuggers and Programmers (ARM-related)
Top
e-holder
e-holder's picture
Level: New Member
Joined: Fri. Aug 24, 2018
Posts: 7 View posts
Posted by e-holder: Fri. Feb 15, 2019 - 09:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes! I have the exact same issue.

 

We are using OpenOCD to program various regions of a SAMV71Q21. We have even dumped the flash and run CRCs, so we know our programming of the flash succeeded. But with a new board, we always have to run a debug session from Atmel Studio with some code before the board will work and run our programming.

 

Our suspicion is that when Atmel Studio uses atprogram behind the scenes to program the board and run a debug session on it, it is also performing some other operation(s). We are speculating it may be writing to some non-volatile memory besides regular flash. Maybe it is:

1) Bootloader code?

2) GPNVM bits so it starts from flash instead of ROM?

3) Setting a reset vector that tells it where to start on reset?

4) Would a chip erase operation properly default other non-volatile memory?

 

I don't know, I'm a bit of a newbie in the microcontroller world. I would like to see the arguments Atmel Studio is adding when it uses atprogram to load the board.

Ed's Law of Debugging: The more bizarre the behavior, the more stupid the mistake.

Top
e-holder
e-holder's picture
Level: New Member
Joined: Fri. Aug 24, 2018
Posts: 7 View posts
Posted by e-holder: Fri. Feb 15, 2019 - 10:10 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I discovered the issue. It is the GPNVM bit. Bit number 1 has to be set to 1 so that it will boot from flash instead of ROM.

 

I have not yet figured out the command syntax to get my OpenOCD programmer code to perform this step, but I'll post it when I do.

Ed's Law of Debugging: The more bizarre the behavior, the more stupid the mistake.

Last Edited: Fri. Feb 15, 2019 - 10:11 PM
Top
e-holder
e-holder's picture
Level: New Member
Joined: Fri. Aug 24, 2018
Posts: 7 View posts
Posted by e-holder: Fri. Feb 15, 2019 - 11:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Solution using OpenOCD and Atmel ICE SWD/JTAG.

 

openocd.exe -f scripts\interface\cmsis-dap.cfg -f scripts\board\atmel_samv71_xplained_ultra.cfg -c init; halt; atsamv gpnvm set 1; resume; exit

 

We executed this from within a Python script (with a little more path details) and it did the trick.

 

Ed's Law of Debugging: The more bizarre the behavior, the more stupid the mistake.

Top
Hillridge
Hillridge's picture
Level: Hangaround
Joined: Mon. Jul 15, 2013
Posts: 172 View posts
Posted by Hillridge: Mon. Apr 1, 2019 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For some reason I almost never get notifications when followed threads are updated.  Thanks for figuring this out, it's been a nagging issue for me.

I will verify it on my end as soon as I have another unprogrammed SAMG55 to test it on, but it certainly makes sense!

 

Edit - Confirmed that factory fresh chips do not have the GPNVM bit set, but that running a debug session on the chip sets it.

 

 

Last Edited: Mon. Apr 1, 2019 - 08:48 PM
Top