Entering Bootloader on Atmel SAMG55 Xplained Pro

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

I am following Atmel document AT09002, Section 1.2 in attempt to put the SAMG55 device into Bootloader mode.

 

I have verified on my oscilloscope that I am strobing the NRST signal appropriately, but my NCHG signal will always stay high, never going low.

 

AT09002 indicates NRST should be taken low for minimum 1ms, and high for minimum 50ms.

This conflicts with the SAMG55 datasheet (indicates the NRST high time should be less than 50ms, and NRST low time greater than 1us)

 

In any event, if I try both timings (NRST taken high for 55ms and 25ms respectively), but NCHG will still remain high after the 10 NRST low sequences.


 

Any other thoughts on how to enter Bootloader mode ?

 


AT09002 indicates toggle ten times in a row, without communicating via I2C or SPI bus between resets.

I have verified that SPI select signal NSS remains high, there are no SPI clock transitions, nor is there any I2C clock transitions.

 

Another Atmel document indicates for SAMG55 ...

     Security bit (GPNVM bit 0) • Boot from bootloader disabled. Boot from flash only. 

I presume this means the Bit 0, should be cleared. Via EDBG, I read GPNVMBITS = 0x02, which indicates BOOT_MODE = 1.

This seems to be OK.

 

AT09002 Section 1.2.1 indicates Bootloader mode after the "force bootloader sequence" detection indicates a "bootloader reset counter" of 10 times.

The application is able to clear the  "bootloader reset counter", which exists at start of RAM at 0x20000000

I have verified my application is not writing to this address ...

 

    I was concerned possibly my app might have been clearing the  "bootloader reset counter" immediately upon NRST being taken high

Mind you, AT09002 is quite unclear here. 

The bootloader reset counter is located at the first address of the device SRAM and its clear value is: 0x00DA1981.

What does this exactly mean ? Do I write that value to 0x20000000 to clear the "bootloader reset counter" ?


 

Any help is appreciated.

 

Thanks, Martin

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

Anybody out there from Atmel Support who may be able to shed some light on this issue ?

 

Thanks, Martin

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

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 !

 

Attachment(s): 

Last Edited: Thu. May 19, 2016 - 06:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thank you Martin, it's very helpful.

 

I'm also using SAMG55 in a project, and I saw the same issue. However, with your information, after I cleared the GPNVM Boot Mode bit, I still could not force G55 to run ROM code -- I had a simple LED application in SAMG55 before I cleared the GPNVM boot mode bit. I should not see the LED enabled after I cleared that bit as there's no application CRC in the flash. But, the reality was that after I used the NRST Toggling Force Bootloader sequence (low in ~1ms, high in ~15ms), the NCHG was still high, and I still could see the LED enabled. It seems G55 is still running flash code not ROM code. Do you have any suggestions on such issue? Is there any other magic bit that I must set/clear to enable the ROM code?

 

Thank you again.

Jerry

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

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

 

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

 

Hi Martin,

 

I too was struggling with putting the SAMG55 into bootloader, I wish I had your clear instructions back then... :)

 

I am now able to enter bootloader and re-program the SAMG55. 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)

 

Have you encountered such differences too?

 

Thanks,

Moti

 

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

Thanks Martin.

 

We just borrowed one SAMG55 evaluation board, and I confirmed that after GPNVM bit 1 was cleared, G55 can enter into the ROM mode (NCHG went low) after the NRST sequence. That means my sequence is correct. However, I still cannot force the G55 on my board enter into the ROM mode. 

 

I compared the silicon part number and found it's G55J19 on SAMG55 evaluation board while it's G55G19 on my board, but I don't think that would lead to the issue I saw.

 

I have contacted Atmel FAE. He will help me to check this strange issue. I'll let you know once the root cause is identified.

 

thanks again.

 

Jerry

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

Sounds good Jerry.

Good to here the manual reset works ... and NCHG goes low.

 

That should only happen because you have a non-CRC'd image in flash. Once you do have a CRC-image in there, you won't see NCHG go low .. because the Bootloader will keep it floating(high) while it verifies the CRC, and it passes the CRC check.

 

So if GPNVM Bit 1 is cleared, and you are at the stage where you don't yet have a CRC image in there, then your 10xNRST should already see NCHG is low immediately, on the first NRST low cycle.

 

If you are able to attach a logic analyzer capture of NCHG and NRST, that would help.

 

Thanks, Martin

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

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

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

 

Thank you very much Martin!

 

Indeed, my application wasn't respecting the 0xC offset from start of RAM and this caused the problem.

(looking at the map file, I could see that variables that belong to the problematic functionality were located by the linker at RAM addresses between 0x20000000 and 0x2000000C)

 

Modifying the linker script to respect the memory boundaries solved the problem :)

 

Thanks,

Moti

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

Hi Marin,

 

Just want to let you know that eventually we can enter into ROM mode. 

 

we made following changes:

+ Just leave NCHG pin with simple pull up circuit. On our board we use this pin for other function in application mode, so we have an additional circuit connected to this pin. To minimize the impact we disconnected the additional circuit and just leave NCHG pin with simple pull up circuit.

+ Power off / on cycle after GPNVM bit1 is cleared. We have a battery on our board, previously we just reset the chip. Now we disconnect the battery then connect it again.

With such changes, then we can see that the LED application does not work, and there're some signal changes on NCHG.

 

Although I don't understand how those changes can impact SAMG55 to enter into ROM mode, but at least ROM is working now, and we can update the application in SAMG55 with the host control code.

 

Thank you for the help.

 

Jerry

Last Edited: Thu. May 26, 2016 - 06:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does any one know if its possible to have SAMG55 self program? Can we write out own custom boot loader sections? So that this boot loader section say reads off an external flash chip and then custom programs the internal flash region? Why do I not see a Read-while-write section in this chip datasheet?

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

Do I have to change something in the linker-script (of the samG55) to respect the crc of the bootloader at flash offset 0x400?

The ram section starts at 0x2000000C instead of 0x20000000. Do I have to do it similar for the flash?   

In AT09002 only the ram-start is modified, but I fear it should be also for the flash.