SAM-BA 2.16 SAMD21G16a bootloader issue

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
erieRider
erieRider's picture
Level: New Member
Joined: Sat. Apr 22, 2017
Posts: 5 View posts
#1
Posted by erieRider: Sun. Apr 23, 2017 - 12:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have programmed my Sparkfun SAMD21G18a minibreak with the samd21_sam_ba_usbcdc.hex  bootloader using my ATMEL ICE.  No problem with the flash and I verified the binary image is flashed using the SAM-BA 2.16 GUI at addresses [0x0000 - 0x0ED8].  Address 0x20000000 contains 0x1000 which indicates that the bootloader resident in the SAMD21 expects the user application to be stored at address 0x1000.    Sweet, now all I have to do is disconnect my ICE, boot the SAMD21 in bootloader mode and use the SAM-BA 2.16 GUI to flash some code.

 

The problem is that the SAM-BA 2.16 GUI does not allow me to flash any user applications in the address range [0x1000 - 0x5FFFF].  It throws a pop-up titled "Attempt to write to monitor area" and OK's me off-stage.  I think I now understand what is causing the problem...

 

The SAM-BA 2.16 uses the profile for a SAMD21J18a when programming a SAMD21G18a part.  On a lead from another forum poster I opened the source: ...\Atmel\sam-ba_2.16\applets\samd21j18a\sam-ba_applets\flash\flash_app_main It contains the ominous code:

//Typical monitor size when compiled (rounded to 8kb upper bound)
#define MONITOR_SIZE (0x6000)

 

Can someone hook me up with SAM-BA ver 2.15 (which I have been told works), provide me with a working SAM-BA 2.16 executable, or provide me with a simple tutorial how to recompile the binary for the J18a part to change this line of code?

 

 

Tags:

Tools, In-System Debuggers and Programmers (ARM-related)
Last Edited: Sun. Apr 23, 2017 - 01:39 AM
Top
Bronze Markjs
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29582 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)
Posted by js: Sun. Apr 23, 2017 - 01:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moved to the ARM side.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
erieRider
erieRider's picture
Level: New Member
Joined: Sat. Apr 22, 2017
Posts: 5 View posts
Posted by erieRider: Sun. Apr 23, 2017 - 02:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, so an answer to one of my own questions, Section 8.5 of the SAM-BA 2.15 USER GUIDE provide instructions on how to re-compile the applet producing the problems.  Unfortunately, it involves downloading a GNU compiler and other utilities.  I have this sinking feeling I'll find myself shaving a yack before long....

Top
Lajon
Lajon's picture
Level: Raving Lunatic
Joined: Fri. Mar 12, 2004
Posts: 2531 View posts
Location: Linköping, Sweden
Posted by Lajon: Sun. Apr 23, 2017 - 08:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found a 2.15 exe. You could also rebuild the boot loader (so both it and sam-ba expect 0x6000). It is an Atmel Studio example project and this is probably the reason for the 0x6000 config since that project has
#define APP_START_ADDRESS          0x00006000
/Lars

Attachment(s): 

Package icon sam-ba_2.15.zip
Top
Lajon
Lajon's picture
Level: Raving Lunatic
Joined: Fri. Mar 12, 2004
Posts: 2531 View posts
Location: Linköping, Sweden
Posted by Lajon: Sun. Apr 23, 2017 - 08:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A bug must be fixed if you build from the example project:
https://www.avrfreaks.net/forum/b...
/Lars

Top
erieRider
erieRider's picture
Level: New Member
Joined: Sat. Apr 22, 2017
Posts: 5 View posts
Posted by erieRider: Sun. Apr 23, 2017 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought about rebuilding the bootloader, but I hate to throw-away the memory between 0x1000-0x6000.  Thanks for the heads-up on the bug fix.

Thanks for the 2.15, you are the man!

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 12040 View posts
Location: Clay County, Texas, u.S.A.
Posted by gchapman: Mon. Apr 24, 2017 - 03:46 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

erieRider wrote:
... Section 8.5 of the SAM-BA 2.15 USER GUIDE provide instructions on how to re-compile the applet producing the problems.  Unfortunately, it involves downloading a GNU compiler and other utilities.
SAM-BA 3 may be an option though it depends on Qt and it has a defect on Windows 10 :

https://github.com/atmelcorp/sam-ba/issues/11 (Windows 10 support #11)

 

"Dare to be naïve." - Buckminster Fuller

Top
erieRider
erieRider's picture
Level: New Member
Joined: Sat. Apr 22, 2017
Posts: 5 View posts
Posted by erieRider: Mon. Apr 24, 2017 - 09:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reply RL.  I overlooked mentioning that I had downloaded SAM-BA 3.14 and to be frank, I am a little bit confused what I downloaded.  I could not find a GUI for SAM-BA 3.0 but did find a command line application.  Weird, but fine, let's launch CMD in windows 10, navigated to the directory, and issues some commands.  Here's the weird part, SAM-BA 3.14 supports a very limited number of devices and definitely not the SAM D 21 devices.  Not sure what was going on with the development team that day???

The solution which works is to:

  • Run the SAM-BA 2.15 tool (thanks Lars!) on my PC.  The 2.15 version allows me to download binaries at or beyond address 0x2000.  The 2.16 version is worth a *!#$ in it present form.
  • Flash, using ICE, the combined USART and USB bootloader on my SAMD21.  This combined bootloader occupies the first 0x2000 bytes of memory and expects the user code to start at address 0x2000.  

This is a waste of 4k of memory, because the Sparkfun SAMD21G18a mini break-out only has a USB connector and I do not expect to need the USART functionality of the bootloader.  But hey it works for now.  I might get motivated and recompile the 2.15 or 2.16 version of the SAM-BA tool to recognize addresses as low as 0x1000.  Shame, it would have been SO easy for the developers to include the lower-bound address as some sort of program option.  After all downloading, and installing a compiler to get a tool to work properly so that you can blink an LED seems a lot like shaving the yack.

 

Top