3

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.

  • 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 Dec 28 '16 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 Dec 28 '16 at 11:37
  • What I'm saying (or half remembering!) is that the host - the PC end - uses one of the unused serial signals - I think DTR - to reset the Arduino and therefore force it into the bootloader again. If you look at a recent Arduino schematic, you may see what the reset pin it tied to. In the original Arduinos it was necessary to manually press the reset button when programming, which was imprecise and frustrating. – Roger Rowland Dec 28 '16 at 11:40
  • 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 Dec 28 '16 at 11:43
  • 1
    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 Dec 28 '16 at 13:02
6

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.

  • 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 Dec 28 '16 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 Dec 28 '16 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy