AVR Freaks

OK, after working with an Atmel FAE, here is how it works. This is specifically for the SAMG55 device.

First and foremost, the NRST Toggling Force Bootloader Sequence will never work until the SAMG55 GPNVM Boot Mode bit (GPNVM bit 1) is cleared.

• This will always force the SAMG55, upon reset, to execute the ROM Bootloader, and execute the flow chart in AT09002 (Figure 3-8)
• Otherwise, when GPNVM Boot Mode bit is set, it would upon reset, just execute your flashed code, never executing the ROM Bootloader

• You can clear the GPNVM Boot Mode bit via Atmel Studio -> Device Programming menu, or a hardware ERASE operation on the SAMG55 chip

OK, once you have this bit cleared, you are ready for next step ...

• Now on every SAMG55 reset, it will run Bootloader ROM code, with logic shown in AT09002 (Figure 3-8)
• BUT your code you program into the SAMG55 flash MUST have special CRC values present in predetermined location(s) as per AT09002 Section 4
• Running the Python script 'hex2fw', you can convert your Atmel Studio-generated build binary file to create this special "CRC" binary file.
• Via Bootloader I2C or SPI operations, you can now program this "CRC" binary file into the SAMG55 flash memory
• Upon the next reset, SAMG55 ROM Bootloader will see the CRC in flash is good, and execute your code properly.
• ... otherwise it stays in Bootloader in the APP_CRC_FAIL state. It will remain there until an external host reprograms the flash memory.

NOTE that if you don't have a Host device yet setup to program the SAMG55 via the Bootloader I2C or SPI, you cannot use the JTAG to program the SAMG55 device 

• This only applies when GPNVM Boot Mode bit is cleared
• You would have to go back and "set" GPNVM Boot Mode, so that it boots directly from Flash. Not too convenient when you are in development mode
• The reason is that the "CRC" binary file generated from the Python script 'hex2fw' has a special format (as defined in AT09002 Section 3.4)
• This "CRC" binary file is ONLY used when programming via the Bootloader I2C or SPI operations

Fortunately Atmel shared with me a modified Python script 'hex2fw' that will generate another binary file in addition to the "CRC" binary file.

• This latter file is suitable for programming via the JTAG port. It is a normal binary file, but with the CRC data placed appropriately in the binary file.
• When using this binary file, you can leave your GPNVM Boot Mode bit in a cleared state
• I have cleaned up this Python script 'hex2fw' so that it is easier to use
• I have attached this script to this issue. Simply add the command line option "-j" followed by the name of the JTAG-compatible binary file you desire.
• Script is named [hex2fw.txt] ... just change extension back to .py

Now when you have the SAMG55 in a system where you want to reprogram the external flash memory from an external host device/microcontroller, you can use the NRST Toggling Force Bootloader sequence outlined in AT09002 Section 1.2

• But to clarify the timings ...
• I set NRST low for 1ms ... there is no upper limit on this, it may work with short duration, but I did not test that.
• When NRST is taken high, there is no upper limit on how long it can be high. I just set it high for 10ms
  • Actually the upper limit on how long you can leave NRST high is governed by AT09002 Section 1.2.1
  • It is highly recommended that your SAMG55 application clear the NRST "counter" by writing to a special RAM location 
  • i.e. C code     uint32_t *reset_counter = 0x20000000;        *reset_counter = 0x00DA1981;
  • Otherwise, on the 10th hardware reset, it would automatically stay in the Bootloader ROM, in the WAITING_BOOTLOAD_CMD state
  • BUT in your SAMG55 application make sure to delay clearing this counter, say 200ms+ into your application.
  • For example, if you reset the counter 200ms into you application, then the upper limit on NRST being high is less than 200ms !
  • Be careful here, otherwise based on the existing code you have programmed into the SAMG55 flash memory, you may have troubles entering the Bootloader, especially if the counter is cleared immediately upon the start of your application.

Otherwise, you are good to go ...

• The ROM Bootloader will operate according to AT09002 Figure 3-8
• Please ignore the status values shown in AT09002 Figure 3-8, they are mostly wrong
• The status values are as outlined in AT09002 Table 3-1

For reference, I have attached a logic analyzer capture (Salae format) for those who may be interested in seeing the Bootloader application update timings (SPI mode)

Thanks !

Hi Jerry,

Now that you have GPNVM Bit 1 bit cleared, don't yet proceed to the NRST Toggling Force Bootloader sequence

Just do a simple single HW reset (if you are using the SAMG55 Xplained Pro board, there is a RESET button)

Just a single reset will take you to the start of the AT09002 Bootloader Flow Chart.

If you don't have an appropriate CRC in your flash image, then the Bootloader will fail the CRC check, and you will see NCHG remain low.

Run the above test first, just to make sure your ROM Bootloader is running. Does NCHG remain low ?

If stays high ... reconfirm via JTAG tool that the BOOT mode is cleared (GPNVM Bit 1) ... sometimes I would see it re-enable ... I think the Atmel Studio would do that if I was programming a non-CRC file ... but I could be mistaken on this ...

If still stays high ... next step is use JTAG tool to erase the flash ...

Then if NCHG is still not going low on a hardware reset, then something weird.

          My main point, is you should be able to see Bootloader entry & NCHG going low without yet proceeding to the NRST Toggling Force Bootloader sequence.

Thanks, Martin

Hi Moti,

However, more than once I've noticed functional differences in F/W behaviour when it was programmed using the bootloader

compared to when it was programmed using the Atmel ICE (with exactly the same F/W of course, on the very same chip)

I haven't seen that (yet).

Make sure that the linker script modifications have been made as per AT09002.

Notably there are 2 areas you need to make sure your application does not use:

• 12 bytes at the start of RAM
• Flash section where the CRC(s) are written to.

If your application is not respecting those boundaries, then yes, you might see some unintended behavior.

Thanks, Martin