SAMS70Q21 flash/fuse programming problems

Go To Last Post
3 posts / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have a custom PCB with a SAMS70Q21 and I am trying to run our application on it but I am trouble simply programming flash and fuses. The application was initially developed using the SAMV71 Xplained Ultra and runs fine on that one. Now I adapted the application to the SAMS70Q21 instead.


First, if I simply click "Start without debugging" in Atmel Studio it seems like flash is programmed successfully (shows writing 0 up to 100%, no error messages), but the application does not seem to run at all (LED should blink).


If I try "Start debugging and break" I can start debug mode but MCU never breaks at the automatically inserted breakpoint in main. The status bar says "Running" though. If I click "Break all" I get disassembly view in address around 0x00800100-0x00800E00 which is ROM - I suspect this is the SAM-BA bootloader. This might have to do with the GPNVM BOOT_MODE bit (i.e. bit 1) having value 0 (boot to ROM) and should be in fact 1 (boot to Flash) so at reset the MCU starts executing the SAM-BA bootloader instead of the application.


However if I try changing (setting to 1) the BOOT_MODE bit through the device programming dialog I get an error message:
Timestamp:    2019-05-06 09:52:47.291
Severity:        ERROR
ComponentId:    20000
StatusCode:    0

One or more registers differs



Reading back the GPNVM value returns all 0's so it seems I cannot set it.


What's more, if I try programming/verifying flash through the device programming dialog I always get verification failure at first memory address:
Verifying Flash...Failed! address=0x400000 expected=0x68 actual=0xff


I tried using atprogram instead to set the BOOT_MODE bit. I get "Write completed successfully" but if I run the "info" command it always indicates BOOT_MODE = 0!


If I try programming/verifying the flash through atprogram I get the same result - programming is successful but verification fails at first address.


I also discovered that atprogram always says "security bit is set" - even if I run the chip erase command. Here's the output from the atprogram "info" command:

atprogram -t atmelice -i swd -d atsams70q21 info
Firmware check OK
Tool atmelice has firmware version: 01.27
Target voltage: 3.22 V

Device information:

Name:       atsams70q21
JtagId:     N/A
Revision:   B
Chip ID:    0xa1120e01
CPU arch.:  CORTEX-M7
Series:     SAMS70

Security bit is set.

Memory Information:

Address Space    StartAddress            Size

base                      0x0     0x100000000
  PERIPHERALS      0x40000000      0x20000000
  SYSTEM           0xe0000000      0x10000000
  QSPIMEM          0x80000000      0x20000000
  AXIMX            0xa0000000        0x100000
  ITCM                    0x0        0x200000
  IFLASH             0x400000        0x200000
  IROM               0x800000          0x4000
  DTCM             0x20000000         0x20000
  IRAM             0x20400000         0x60000
  EBI_CS0          0x60000000       0x1000000
  EBI_CS1          0x61000000       0x1000000
  EBI_CS2          0x62000000       0x1000000
  EBI_CS3          0x63000000       0x1000000
  SDRAM_CS         0x70000000      0x10000000

fuses                     0x0             0x1

lockbits                  0x0            0x10

GPNVMBITS (0b0000000000000000 <-> 0x0000):
   BOOT_MODE     0

LOCKBIT_WORD3 (0b00000000000000000000000000000000 <-> 0x00000000)
LOCKBIT_WORD2 (0b00000000000000000000000000000000 <-> 0x00000000)
LOCKBIT_WORD1 (0b00000000000000000000000000000000 <-> 0x00000000)
LOCKBIT_WORD0 (0b00000000000000000000000000000000 <-> 0x00000000)


So this boils down to:
1) writing flash and fuses from Atmel Studio and atprogram indicates success
2) reading flash and fuses from Atmel Studio and atprogram always returns incorrect data
3) MCU seems to execute something else than my application


Version information:

Atmel Studio 7.0.1931 (Atmel kits 7.0.122)

atprogram version 6.2.1116.0

Atmel ICE FW 1.27.

This topic has a solution.

/Jakob Selbing

Last Edited: Mon. May 6, 2019 - 12:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just tried hooking up my PC to the UART0 of the MCU and tried some SAM-BA commands from Tera Term and as I suspected the SAM-BA program is indeed running and replying properly. So I guess the BOOT_MODE bit is not properly programmed and MCU just boots into SAM-BA instead of the application in flash.

/Jakob Selbing

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After contact with Microchip support (fast reply!) I discovered that PB12 was connected to a pull-up and used for reading a mechanical switch. The PB12 has an alternate function - if it is logic high at reset it will make the MCU perform a chip erase. So on each reset the chip would perform chip erase! :/


Spent 3 days on that one...

/Jakob Selbing