AVR- Entering Boot mode without using Physcial pin

[sanka1p]

Hi All,

I am using the Bootloader provided by Microchip for AVR 0 series for Atmega1608. For reference the Application note numbered AN2634. I was able to flash my Bootloader and my Hex file without any issue using the method of physical boot pin needs to be pulled low initially to get the MCU in boot mode. Now, I want to enter boot mode without having to change the Pins physical state like pulling it high or low. Application note mentions that we can enter boot mode by changing USERROW value and checking that initially while powering up. My question is, how can I change the value in USERROW to trigger boot mode?

[ataradov]

There is an example code right in the document.

Do you want application to invoke the bootloader or something else? What exactly?

User Row is non-volatile memory with a limited number of write cycles. I personally prefer to use SRAM for the same purpose. When application wants to call the bootloader, it places some pattern of bytes in the first 16 bytes of SRAM and resets the device. Bootloader checks for that pattern on boot. If the pattern matches - it stays in the BL mode, otherwise it runs the application. SRAM content is random on power up, but it is preserved over resets.

[sanka1p]

Do you want application to invoke the bootloader or something else? What exactly?

User Row is non-volatile memory with a limited number of write cycles.

How can I set the Initial value of USERROW?

[ataradov]

What do you understand by the initial value? If you mean the value set at the programming time with a debugger, then I have no clue how it is done on AVRs. Programmer can set those bytes, but how you specify that data in the  code - no idea.

But given that it is EEPROM, it would likely be 0xff from the factory, so if you pick that value as a trigger, it would just work without programming it initially.

[sanka1p]

In my boot.c when I use Physcial pin as boot pin. My system works perfectly fine, I am able to flash my F/W hex file through the bootloader normally. Now when I am using USSERROW, and trying to flash my Hex file. I get an error on command prompt saying "Failed at address 0x0100. Value 0x00 echoed, expected 0x0c". I am attaching my boot.c file in USERROW case. Please take a look at it.

[ataradov]

Bootloader should be requested if the value of the fuse is 0xff. You have it the other way around.

The way you debug things like this, even if you don't have a debugger is by togging a pin.

Before you do anything else in the boot() function check the value of the USERROW.USERROW31 and toggle a pin if it is the value you expect. Then check if the pin toggles.


But also, why have you removed the write of NVMCTRL_CMD_PAGEERASEWRITE_gc and a wait for NVMCTRL_EEBUSY_bm? This is the part that actually updates the value in the persistent storage.

[sanka1p]

I made the changes you suggested, I am able to flash my hex file into the MCU, but it is not working. I mean it is not flashing LEDs. I am attaching both boot.c file and my main F/W main.c file. Can you please take a look at it. I am using IAR IDE for the LED flashing F/W. My hex file address starts from 0x100. I checked that.

[ataradov]

Use the same exact application binary you used for testing the original pin-based version. Don't change too many things at once.

How do you place initial 0xEB value in the USERROW31?

Ok, I actually don't get the logic here. If USERROW31 is 0xEB, then you are requesting to run the application. But how would 0xEB get there in a first place?

Assuming USERROW31 is 0xff by default, the code should be something like:

Code: [Select]

static bool is_bootloader_requested(void)
{
if (USERROW.USERROW31 == 0xFF) 
{
/* Clear boot request*/
USERROW.USERROW31 = 0xEB; // Any non-0xFF value
_PROTECTED_WRITE_SPM(NVMCTRL.CTRLA, NVMCTRL_CMD_PAGEERASEWRITE_gc);
while(NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm);
return true;
}
  return false;
}

This will request the BL and simultaneously clear the flag.

And then to enter the bootloader, you write 0xff from the application.

Ok, I see where the issue is. You incorrectly copied the code from the appnote. And your comment "this will enter boot mode" is not correct. "Return false" will run the application.