Saturday, January 11, 2020

Picoboot v3 with autobaud and timeout

Today I released v3 beta2 of picoboot.  Like the last release of picoboot, it takes up only 256 bytes, which is the minimum bootloader size supported on the ATmega88 and ATmega168.  This means picoboot will free up 256 bytes of flash if you currently use Optiboot.  Without any potential benefit from reduced size, this release focused on robustness and speed.


The above screen shot shows reading the 16kB flash memory of an ATmega168 in 1.32 seconds.  Using 500kbps instead of 250 will read the flash in under one second, and will read 32kB of flash from an ATmega328 in two seconds.  Not only is it fast, it is reliable, with no errors using CH340G and CP2102 adapters under Windows, and PL2303HX adapters under Linux.  So as long as your serial driver supports 250 or 500kbps and doesn't round them down to 230,400 and 460,800, you can have reliable and high speed uploading and verify of code on ATmega MCUs.

Earlier versions of picoboot supported a bootloader toggle mode, where resetting the MCU once entered the bootloader, and resetting again ran the application code.  I designed this with boards that don't support the auto-reset functionality of the Arduino bootloader.  However this turned out to be problematic with some boards that do have auto-reset, where picoboot could sometimes toggle out of bootloader mode when it was supposed to enter bootloader mode.  With v3, picoboot now implements a timeout where it will wait for a few seconds and if no communication is received from avrdude, the bootloader will exit.

Like the previous versions, picoboot does not use the watchdog timer, and will not impact application code that uses the watchdog reset.  To make picoboot useful for use with a standalone AVR on a breadboard, it does not rely on a user LED on PB5 to indicate bootloader activity.  Instead, when the bootloader starts, it lowers the TXD line (PD1).  This will light the RX LED on the attached serial adapter.  If the bootloader times out, PD1 will be left floating before the bootloader exits.

My recommended baud rate for picoboot is 250kbps.  This baud rate results in 0 timing error with the AVR USART when used with the common clock rates of 8, 12, and 16Mhz, as well as the less-common 20Mhz.  The faster 500kbps also results in 0 timing error with the USART, however poor design of some serial adapters  makes the higher speeds more susceptible to noise, particularly when long wires are used to connect to the AVR.  I didn't encounter problems at 500kbps, but I was a bit surprised by how much noise I saw on my oscilloscope when testing a CP2102.

If you are using the Arduino IDE rather than the command line, I explained how to change the boards.txt file in my blog post about picoboot v1.

I plan to test v3 beta 2 for about a month, so expect the final v3 in early February.  In addition to further testing on the mega168 and mega328, I'll test the mega88.  If there is enough interest in a build for the mega8, I'll look into supporting it too.



7 comments:

  1. Thanks a lot for yout effort. I usually use MCUSR register to know why my atmega328p has reset. Do you modify it in your code ? Thanks

    ReplyDelete
    Replies
    1. No, picoboot uses a busy loop timeout. The code is slightly more complicated than if I used the watchdog timer like optiboot, but it doesn't have the issues with MCUSR.

      Delete
  2. very nice project, Arduino Nano 168p works perfectly at baud 115.2k or 250k, but 230400 does not.

    ReplyDelete
    Replies
    1. That's to be expected. 230.4kbps doesn't work out to an integer UBRR value, whereas 250kbps does.

      Delete
  3. It's a very good bootloader, especially when there is very little space left from the application program. Thank you for your tremendous effect. I do have a problem with the bootloader not exiting when the USB cable is not connected. Otherwise, the bootloader will start the application after 2.5 second time out. Is there a fix for that?

    ReplyDelete
  4. Did you see https://github.com/avrdudes/avrdude/pull/1171#issuecomment-1307776158 ?
    The "avrdude guy" has implemented a new comm protocol aimed specifically at bootloaders, rather than at hardware programmers, and apparently it enables even smaller bootloaders.

    ReplyDelete
    Replies
    1. Lately my development work has been high-level languages, mostly python, so I hadn't seen it. Thanks for the tip.

      Delete