Wednesday, February 26, 2014

Picoboot beta1 release

Today I've released the beta-1 version of picoboot.  Requiring only 66 bytes of flash, picoboot is the smallest AVR bootloader, taking a quarter of the space required by other "tiny" bootloaders which start at around 512 bytes.  Not only is it the smallest available bootloader, it is the smallest possible bootloader for AVRs with a 64-byte page size.  Picoboot is also fast, taking less than 3 seconds to write 8126 bytes to flash.

Future plans include builds for the ATtiny2313a and support for zero-wire auto-reset.

$ avrdude -c picoboot -p t85 -P com16
drain><drain

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e2a00
avrdude.exe: programmer operation not supported
avrdude.exe: programmer operation not supported
avrdude.exe: programmer operation not supported

avrdude.exe done.  Thank you.

7 comments:

  1. Hi Ralph:

    Thanks for sharing your work. I've tried to make it work using an old attiny84, with 8Mhz fuses burnt using Arduino IDE:
    1. I have burnt picoboot using USBasp:
    avrdude -p t84 -c usbasp -u flash:pb-t84-t85-8Mhz-b1.hex

    2. I have changed avrdude and avrdude.conf by those in http://162.248.164.251/files/

    3. I have connected and old Nokia cable using PL-2303 to ports PB0 and PB1

    4. I compiled Blink sketch using arduino IDE for attiny84-8Mhz thorugh the serial cable:
    avrdude -c picoboot -p t84 -P com3 -U flash:w:Blink.hex

    A series of never-ending hexadecimal bytes appears. Anything wrong? fuses?

    drain>00 00 ff 00 ff 00 00 00 ff 00 fa 00 fe 00 fe 4b 00 f6 9b 00 ff 00 ff 00 f6
    00 ff 00 fe 00 ff 00 ff 00 fd 00 ff 77 00 00 fe 00 ff 00 ff 00 ff 00 fa 00 ff 0
    0 ff 00 fa 00 ff 37 00 00 f6 00 ff 00 fe 00 ff 37 00 00 ff 00 fe 67 00 00 ff 00
    fa 2d 00 ff 4b 00 fe 00 fe 00 ff 00 ff 00 ff 00 fa 00 fe 00 f6 00 fe 00 ff ad 00
    fa 00 fa 00 ff 00 ff 00 ff 00 ff 00 00 fe 00 ff 00 fa 00 00 ff 00 ff 00 fe 00 6
    7 00 ff 00 00 fe 00 f6 00 29 00 fa 00 00 ff 00 ff 00 ff 00 fe 37 00 ff 00 00 00
    f6 00 ff 00 00 00 00 fd 9b 00 4b 00 ff 00 ff 00 fa 00 fa 00 2d 00 00 ff 00 fe 00
    00 fa 00 ff 00 00 00 fe 00 ff 97 00 ff 00 fe 00 fe 4b 00 fb 29 00 ff 00 f2 00 f
    a 00 ff 00 00 fd 00 ff 00 00 fe 00 16 00 ff 3f 00 00 fa 00 fe 00 00 ff 00 00 00
    fc 00 ff 00 ff 00 fc 00 ff 00 ff 00 fa 00 ff 00 00 ff 00 ff 00 ^C

    Thank you

    ReplyDelete
    Replies
    1. Do you have pin 2 (PB0) connected to the Tx line on your PL-2303 and pin 3 to the Rx line?
      When the bootloader is running it should bring tx (PB1) low while it waits for communication from avrdude. I don't think those Nokia cables have LED indicators, so I'd suggest an LED from Vcc to PB1 with a ~1K series resistor to test it. If the LED doesn't light up when you power up the t84, either the booloader wasn't properly flashed or it didn't detect ttl idle (high) on PB0.

      I'd also suggest you pick up a USB-ttl adapter that has LED indicators for Tx and Rx - they're cheap and the LEDs help troubleshoot communications issues.
      http://www.fasttech.com/products/0/10003090/1230400-pl2303hx-33v5v-ttl-logic-level-usb-serial-port-ada

      Delete
    2. Thanks Ralph. Some changes:
      - I turned on PTRGEN efuse with USBasp
      - tested the serial cable: modifying Blink (led on pin 7) with BasicSerial.S, configuring UART_Tx=1. After burning the sketch with USBasp I could read bytes printed by attiny
      - burnt again the booloader 'with USBasp, done ok, but it's strange, the led blinking on pin 7, either burning with unmodified avrdude or with the modified one
      - burnt the blink sketch using serial port and modified-avrdude:

      drain><drain

      avrdude: AVR device initialized and ready to accept instructions

      Reading | ################################################## | 100% 0.02s

      avrdude: Device signature = 0x1e2a00
      avrdude: NOTE: "flash" memory has been specified, an erase cycle will be perfor
      ed
      To disable this feature, specify the -D option.
      avrdude: erasing chip

      avrdude: picoboot_wait_ack(): protocol error, expect ACK=0x00, resp=0xffffff86

      Delete
    3. I haven't heard of a fuse setting called PTRGEN. I checked the tiny84 datasheet and couldn't find a reference to it either.
      If you changed UART_TX to 1, then you need to connect the Rx line on your serial module to Pin 3 on the t84 (PB1), and the tx line to pin 2 (PB0) assuming you defined UART_RX as 0.

      Delete
    4. Sorry for the typo. I meant SELFPRGEN. From the datasheet the SPM (self-programming) instruction is disabled by default but it can be enabled by programming the SELFPRGEN fuse (to “0”).
      avrdude -p t84 -c usbasp -U efuse:w:0xFE:m

      "Before programming a page with the data stored in the temporary page buffer, the page must be erased. The temporary page buffer is filled one word at a time using SPM and the buffer can be filled either before the Page
      Erase command or between a Page Erase and a Page Write operation"

      From avrdude output, it seems that the bootloader received some initialization sequence but it loses sync after the erasing command and before a writing operation (the ACK is lost). If I invert TX and RX, The "AVR device initialized" line will not be printed, so I suspect from some communication problem between avrdude and the bootloader, maybe due to the transmission speed?

      Delete
    5. OK, that makes more sense. The SELFPRGEN fuse definately needs to be set.
      The only other thing I can think of is to make sure the CKDIV8 fuse is not set. If it is, the MCU will run only at 1Mhz, causing the serial communication to run at 1/8th speed. (28.8kbps instead of 230.4 kbps)
      If it is running at 8Mhz, it's possible the RC oscillator is not as accurate on your t84 as it is on the t84a's I tested. You could rebuild the source with the RXDELAY, RXSTART, & TXDELAY modified for slower serial speed such as 57,6kbps. You'd need to change avrdude.conf or specify the baud rate on the command line.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete