So I want to enter the bootloader of an Arduino nano (Chinese version with old bootloader). I tried using an watchdog reset but it doesn't enter bootloader and only ends in an infinite watchdog reset loop (I know this is an known issue)! I read in this Post: Reset to bootloader through sketch - Development - Arduino Forum
that this problem is related to the following lines in ATMEGA Boot:
// Check if the WDT was used to reset, in which case we dont bootload and skip straight to the code. woot.[color=#222222][/color]
if (! (ch & _BV(EXTRF))) // if its a not an external reset...[color=#222222][/color]
app_start(); // skip bootloader
ch is MCUSR, I set it to 0 when restarting!
But what is EXTRF?
I know I could comment out this line to get it to work! But to do this I would need to build an ISP Programmer, which I only want to do if its absolutly needed!
So is there any possible option to reset this Arduino Nano to enter bootloader correctly? or do I have to change Bootloader?
and if I have to change bootloader would Optiboot be a better solution for my Problem?
MCUSR is status register and EXTRF is the external reset flag - a bit in MCUSR. I'm recommending to read ATmega328P data sheet if you want know more about it.
Why would you built the ISP programmer. Any cheap ISP programmer is good, like most common USBasp. You can also use another Arduino as ISP programmer.
There is a possibility to call the bootloader directly, a jump to the address of the bootloader. Not the same as reset but it should work.
Optiboot is good choice and it is smaller than bootloader usually used in chinese Nanos. It takes 512B in compare with 1kB for the old bootloader. Optiboot image is created for 115200 baud trnsfer speed, the old bootloader has it for 57600 baud, but you can compile it for your needs of course.
Okay! Thank you!
With ISP Programmer I meant an Arduino one....
I may have an look into jumping to the right address... But I guess this isnt very consistent/reliable?
I know Optiboot has these advantages, but would it help with jumping into the bootloader?
Truly, I've never tried exactly this myself. I've just used jump to 0 address to start the APP directly. The difference against the RESET or like watchdog it does, is in e.g. I/O initial setting. They are in the high impedance state after the reset.
Anyhow, I do not see any essential problem to do this. You would inform us about the result.
The address of the bootloader is in e.g. according the datasheet for 328P - boot regions and their sizes. You can use ASM instruction for jump JMP or define the function and just call it.
// ASM call
__asm__ __volatile__("JMP 0x7C00" );
// C function
void (*b)() = (void (*)())0x7C00;
// then somewhere in program
b();
Old bootloader uses 1024 so the address should be 7c00h.
Personally, I would prefer watchdog with Optiboot.
Thanks a lot!
I will try to jump to this address, since it easy to implement. However I dont think this will work because watchdogs is defined in the main loop of the bootloader therefor it propably will still escape the bootloader...
I tried to send a command over serial to it to restart it self and then upload a Programm over an Mkr Zero! Sadly Budvar10's suggested "address jumb" didn't work, because the extrf flag wasnt correct! But now I updated the Bootloader and added a reset pin from the master and everything works finenow
An interesting topic - which raises a couple of interesting points which I was surprised nobody mentioned....
First off, while using Optiboot has many advantages over other serial bootloadersbeing able to enter the bootloader after a reset is not one of them! in fact, a WDT reset is the one reset source that can't be a valid entry source for the bootloader without putting some thought into how to modify it to achieve that. The reason being that you can only clear bits from MCUSR, not set them, but Optiboot is built with the intent that when optitboot exits, it will do that exiting via watchdog reset, restoring the chip to a freshly reset state for the application. And that's why optiboot never runs on a WDT reset. A couple of years back I tried briefly to make a WDT-reset-enterable optiboot. After I figured out why my attempt made it stay in optiboot forever, I decided to that other priorities mattered more. I
The other thing is, I seem to recall there being hazards to jumping direct to the bootloader, cases where it can break; not that it can't be done, but just that there are a few boxes you have to check.....
Budvar10:
Optiboot is good choice and it is smaller than bootloader usually used in chinese Nanos. It takes 512B in compare with 1kB for the old bootloader.
The Nano bootloaders, old and new versions, have the fuses set to allocate 1k words of flash memory, which is 2k bytes. The new bootloader is optiboot, same as used on the UNO, only the fuse settings differ.
I have in my setup 0xDE - 512B for the new botloader (Optiboot). Howewer, I'm not using recent version. I do not understand why, because Optiboot image is the same as for UNO, 512B. There is no reason or I do not see any at least. Anyway, there is a possibility to customize it or to use UNO setting for Nano.
+1
Budvar10:
I have in my setup 0xDE - 512B for the new botloader (Optiboot). Howewer, I'm not using recent version. I do not understand why, because Optiboot image is the same as for UNO, 512B. There is no reason or I do not see any at least. Anyway, there is a possibility to customize it or to use UNO setting for Nano.
The original (old) bootloader used on the Nano was large enough that 2K bytes was needed. When the change was made to optiboot, for some reason the fuse settings were not updated to reflect the smaller size of the bootloader. Not sure whether this was an inadvertent mistake, or done to preserve compatibility, since code that actually needed the additional memory available with a 512 byte bootloader section would then fail when compiled for the old bootloader.
It is very common to burn the bootloader to a Nano with the settings for an UNO, then set the IDE for UNO when programming. The only real difference between an UNO and a Nano, as far as programming is concerned, is the addition of analog ports A6 and A7 on the Nano, but those pins are defined and usable under the UNO settings and will work properly - the ports physical exist on the processor chip used for the UNO, but are left unconnected because the packaging does not have sufficient pins.