4

For the sake of specificity I am referencing my question to Arduino. It applies to all AVRs with hardware USB and a bootloader though.

The bootloader is capable of receiving new program data over the USB interface, and, after programming, releases the interface. It can then for instance be used for the emulation of a serial port, or even register as a HID.

I know what a bootloader is and how it reads program data from the PC and how it writes it to the devices flash memory.

I am asking how the bootloader is triggered again if the user wants to upload a new program. The PC needs to reset the AVR in order to fire up the bootloader. How is this reset instruction implemented in Arduinos with built-in USB hardware (e.g. the Arduino Micro)? Is it solved by performing a software reset after the DTR line goes low just as in e.g. the Arduino Nano, except that the DTR line only exists in software?

EDIT: If that is the case, the solution is unique to Arduinos. I was thinking that there would be some standard way of doing it common to all AVRs.

Improve this question
9
  • AFAIR, the Arduino uses the DTR signal from the serial port as a way for the host to trigger a reset of the board (it has nothing to do with USB). This is documented somewhere but I don't recall where.
    – Roger Rowland
    Commented Dec 28, 2016 at 9:40
  • @RogerRowland So you are saying that after the USB-to-serial decoding is done (in software, on the MC), a change in the (virtual) DTR line triggers a reset?
    – polwel
    Commented Dec 28, 2016 at 11:37
  • 1
    Yes, I know that, but I am specifically asking about AVR with built-in USB capabilities, like the ATMega32u in the Arduino Micro. The USB data lines go directly into the chip. There is no physical DTR signal that could be wired to the reset pin.
    – polwel
    Commented Dec 28, 2016 at 11:43
  • 2
    Closing this question was premature, the OP asks a very specific question, which I don't see answered on the linked question.
    – Wouter van Ooijen
    Commented Dec 28, 2016 at 13:02
  • 1
    Funny side note: the arduino Due (my favourite) has a separate usb-serial chip, but still uses the "1200 baud" reset (but because it is handled by a separate chip it is a hard reset, unlike on the micro). Unaware of this I once spent a few hours trying to get the serial interface of a Due to work at 1200 baud....
    – Wouter van Ooijen
    Commented Dec 28, 2016 at 13:09

1 Answer 1

Reset to default
7

On microcontrollers with bootloader (not just AVRs), the bootloader is a separate executable in flash, and it's typically the program that runs on system startup. The application will have a special trigger, such as a button sequence, getting a specific byte sequence over I2C, or really anything that will tell the bootloader to enter into its "update" mode. From there, the bootloader will have some communication (I2C, USB, WiFi, serial, etc) to download and the flash the new application image.

This link has more information about the Arduino bootloader

On the PC side, to trigger a reset on the RESET pin, the PC (avrdude.exe or GNU/Linux equivalent) opens the serial port to Arduino when your press upload and the code is ready to upload. This causes the Data Transmit Ready (DTR) line of the USB/TTL chip to go LOW. The Arduino board has a capacitor charging circuit that uses this LOW (charging the capacitor) signal to momentarily pull down the RESET line of the ATMEGA328P chip before returning it to HIGH (capacitor charging completes). So Arduino resets each time its serial port is opened.

Upon reset, Arduino enters the bootloader.

The bootloader looks at the source that caused the reset. There are several sources that can cause a reset. If the reset was caused by the RESET pin, then it waits for one second for the PC to send in commands. When it receives valid commands, it will start accepting new Arduino code in HEX format and erase the existing code to load new one. If it doesn’t receive valid commands, it times out after one second and triggers a Watch Dog Timer (WDT) reset.

For Arduinos with built-in USB, such as the Micro, the Arduino library (firmware) triggers the system reset. There's a little chunk of code that looks for the virtual COM port to open at 1200 baud and then close. When that happens, the code triggers a system reset (by writing a register, typically) which launches the bootloader.

Rather than requiring a physical press of the reset button before an upload, the Micro board is designed in a way that allows it to be reset by software running on a connected computer. The reset is triggered when the Micro's virtual (CDC) serial / COM port is opened at 1200 baud and then closed. When this happens, the processor will reset, breaking the USB connection to the computer (meaning that the virtual serial / COM port will disappear). After the processor resets, the bootloader starts, remaining active for about 8 seconds. The bootloader can also be initiated by pressing the reset button on the Micro. Note that when the board first powers up, it will jump straight to the user sketch, if present, rather than initiating the bootloader.

Because of the way the Micro handles reset it's best to let the Arduino Software (IDE) try to initiate the reset before uploading, especially if you are in the habit of pressing the reset button before uploading on other boards. If the software can't reset the board, you can always start the bootloader by pressing the reset button on the board.

Personal story: I wrote an I2C bootloader for the PIC32. The only communication with the device was through the I2C bus. The main application had a special 3 byte trigger that would set a non-initialized variable in RAM, and then trigger a system reset. The bootloader, which runs on system startup, would check that variable and if it was set, would wait for commands over I2C to download and flash the new application image. That variable in RAM had to be specially marked as non-initialized, otherwise the C startup code would clear it and the bootloader would never update.

The bootloader also calculated a CRC32 over the application image to validate it before attempting to boot. If the calculated CRC32 didn't match the stored CRC32 (which was part of the application image), then the bootloader would enter its firmware update mode. This was a guard against trying to run a corrupted firmware image, which could happen if power was pulled during the update process.

Improve this answer
2
  • 1
    Thanks for the answer. Unfortunately it still misses my main point. I know that e.g. the Arduino Nano has the DTR line hardwired to the reset pin, so the PC can reset the AVR by pulling DTR to ground. How is it done for AVRs with built-in USB hardware? Do the Arduino libraries perform a software reset upon a change in the virtual DTR line?
    – polwel
    Commented Dec 28, 2016 at 12:02
  • @polwel I updated the answer to hopefully provide more information about Arduinos with buit-in USB. The bootloader trigger is done within the Arduino virtual COM port library.
    – CHendrix
    Commented Dec 28, 2016 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.