Hello, I wanted to flash this .ino on an Arduino Nano
But in the comments it says "Also, the Arduino must be flashed using SPI (deleting the bootloader), since I expect a signal ~1 second after power on."
I have an Arduino Uno flashed with ArduinoISP, will it be enough if I flash the Arduino Nano with the "Flash using a programmer" option? Or are there more things to do?
I don't know if I should use the "Burn bootloader" option.
Yes, that will wipe the bootloader.
Thank you, there are some people who talk about configuring the "fuses" I can't find anything on this subject
We can choose bootloader and old bootloader but I think that in this case it makes no difference since the bootloader is deleted?
If I flash using a programmer and then do "burn bootloader" should it overwrite the code or only part of it?
When you buy a Nano or burn the bootloader, the fuses are set.
When you upload using programmer, the bootloader is deleted so it indeed makes no difference.
Burning the bootloader will completely overwrite the sketch that was loaded.
Thank you for your help
Theoretically, if you're using "upload using programmer", you should also change the fuses to reflect that the bootloader is not present. In practice, this is only "necessary" if your program is longer than the 32256 bytes long; if you don't do it the AVR will start in the "wrong" place (where the bootloader used to be), but it will just execute 256 nop-like instructions (taking about 16us) before getting to the start of your application.
I believe "minicore" will let you correctly set the fuses (with "burn bootloader") by configuring the "Bootloader (none)" option in the tools menu, after you select atmega328 as the primary board type.
Say, I have erased the 328P MCU and all locations contain FFs. After that, I have set the fuse bits for the MCU to boot at location 0x3FF0. Even the chip is not erased, the Boot Sections will hold random values.
Now, the MCU will begin program execution at location 0x3FF0 where the opcode is 0xFFFF and NOT 0x0000 (for No operation). I think the MCU will hang as it will not find any jump instruction to reach at location 0x0000 and then at the application.
If you have AVR Programmer or Parallel ROM Programmer, you follow the description of the fuse bits as given in the following chart (Fig-1) to set the boot loaction at 0x0000.
0xFFFF is not a nop, exactly,which is why I said “nop-like.”
(I think “SBRS r31,7” - a conditional skip)
When the PC reaches the end of memory, it simply wraps around to 0x0000, where the app actually starts.
1. Right!
2. I checked with AVR Instruction Set that the opcode is NOT exactly 0xFFFF; it is 0xFFF7. I will shortly check it experimentally to see that 1. is justfied and the MCU does not hang.
3. This has to happen if 1. and 2. are satisfied.
Bravo!!
If the Nano has the current bootloader, instead of the "old bootloader", then this should not be a problem. The newer versions of optiboot check to see what caused the processor to reset and will go directly to the user code when the power is initially applied. The delay still occurs if the reset input is triggered.
I have just checked/verified by running a stand-alone ATmega328P with boot location is set at 0x3C00that that the application program executes (a blinking LED) even the Boot Section contains all 0xFFs.
Bravo again!! I have learnt a new thing.
Thank you for your help, but I don't understand what it means to configure the fuses, how do I know if it was originally an old bootloader or not ?
I programmed the NANO following this guide https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP/ , with an arduino UNO, the program works but it's good to understand what we're doing too
Then you need -
2 or 3 pieces of ATmega328P chip and its data sheets.
AVR Programmer. or Parallel ROM Programmer.
5V Power Supply.
Breadboard.
Jumper Wires.
PC.
LED.
2.2k Resistor.
Well, by reading the existing fuses.
This is "easy" to do with avrdude from the command line; you just need to type in a command like:
/Applications/Arduino-1.8.19.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/Applications/Arduino-1.8.19.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf -patmega328p -cstk500v1 -P/dev/cu.usbserial-FTD61T6Q -b19200
You'll get output that includes:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.05s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)
The "interesting" fuse here is the H (High) Fuse. The low three bits of that control the bootloading behavior. Bit 0, if 0, means to start at the bootloader address.
Bits 1 and 2 select the bootloader size. 0b11x means 512 bytes (Optiboot, the "new" bootloader.) 0b01x means 2048 bytes ("Old bootloader" (Atmegaboot))
0bxx1 means no bootloader.
So DE as shown above is 0b11011110, so it's running optiboot.
to disable the bootloader using just avrdude, you'd use a command like:
avrdude -patmega328p -cstk500v1 -P/dev/cu.usbserial-FTD61T6Q -b19200 -e -Ulock:w:0x3f:m -Uhfuse:w:0b11011111:m
(note that you do NOT want to change the high bits of the fuse. Bad things would happen! This is why it's probably better to use the "burn bootloader" command of minicore...)
The "new" bootloader still uses the 2048 byte setting, even though it only needs 512 bytes.
@westfw is likely seeing 512 because he has burned the bootloader to the Nano while setting the board type to UNO in the IDE - a very common practice to recover the wasted 1.5Kbytes of flash memory.
Unless you can remember the behaviour of the L-LED after a reset, you can not determine what the bootloader was, only what it is. The old bootloader gives a single flash on the L-LED after reset, the new bootloader gives 3 quick flashes after reset,
Ah. Right. We were talking about Nanos. An uno o would have the fuses as I describe.
That makes it harder to tell which version is on the chip.
You could write a sketch that turns on an LED on a pin other than 13 at the very start of setup(). Then apply power and see how long it takes for the LED to turn on. That would let you know the delay time at the initial power on reset.
Alternatively, avrdude can be used to download the contents of the flash memory. That would allow you to examine the bootloader location and see what is there.
Really more trouble that its worth. Just burn the bootloader of your choice, or remove the bootloader entirely since that was the original objective, either way requires an ISP programmer.
Optiboot (the "new" bootloader) has a version number in the last word of flash.
Somewhere between 0x0404 and 0x0308 ("Major Version" in the LSB (first byte), "Minor Version" in the MSB) I believe the old bootloader will just have 0xFFFF there.
(Hmm. "Minicore", which I've been recommending, has upgraded to yet another bootloader ("urboot"), so using it might introduce additional confusion. (Although I was recommending it for its support of "no bootloader."))