Bootloader for AVR-ATtinys with one pin photodiode optical interface

[eneuro]

Hello,
Maybe someone used this 550 bytes TinySafeBoot - A tiny and safe Bootloader for AVR-ATtinys and ATmegas and tried something else than this claimed

One-wire, also with multiple AVRs on a single line

I mean, one AVR only pin photodiode optical interface, to be able send new software to AVR device without any wiring just using "smartphone", tablet or other decent illumination light source  using this bootloader? 

It looks like this TSB for ATtiny can update itself, which sounds nice, but will it work using different light signals instead of wires using only one wire more and one way communication from light source to this photodiode or phototransistor enabled one MPU pin ? 

Update: Nope, this simple CI-V example interface http://www.qsl.net/g3vgr/civ.html needs bidirectional communication, but unfortunatelly with LCD or cell phone screen no way to send data in both directions-only out of LCD/phone/tablet, so something more fancy needed or changed simplified source code of this TSB needed to be able only Tx data from LCD and Rx on MPU pin, eg. using something aka Morse code interface, etc, so probably only TSB genaral concepts will be usable and we'll try design custom TinyLightBoot (TLB)  based on TSB flash memory adresses, to be able use TSB when its oryginal PC software available and CI-V One Wire interface-while in production environment TLB to ensure galvanic insulation between MPUs and end users handheld devices, so it is time try to  TSB source code to support aka Morse code communication using only one pin and MPU pin in input mode after hardware reset with oryginal TSB concept in mind to be compatible with flash address spaces for boot loader...

[ralphd]

This circuit lets you program an avr using a headphone jack.
https://hackaday.io/project/4926-cheepit-sparrow-dev-boards-for-smartphones

[eneuro]

This circuit lets you program an avr using a headphone jack.

Yep, but I wouldn't like to mess on some HV PCBs with connecting handheld device without galvanic insulation between them, so wire connection is not an option, especially while I'd like program those devices directly from my WWW page where end user will be able to set some software options and get software update directly for his device with AVR LOCKBITS set to MODE 3 for enhanced security to prevent reading MPU memory using ISP-only bootloader protocol and MPU teradown by service authorized person will be able use wires to connect to MPU, but still with a few kV insulation between light software sender and photodiode/phototransistor  with floating power supply attachable to given MPU bootloader pin, to ensure no chance for any electric shocks due to crappy handheld devices wall socket power supply, etc.   

[ralphd]

Picoboot could work in a one-way mode.  Just change the avrdude patch to time the page write commands instead of waiting for the ack.
https://github.com/nerdralph/picoboot
And its 1/8th the size of tsb...

[matseng]

...., to ensure no chance for any electric shocks due to crappy handheld devices wall socket power supply, etc.

That sounds very uber paranoid  - do you usually also use an additional isolation transformer between the wall and your cell phone charger for "that extra protection"?  O0

[eneuro]

do you usually also use an additional isolation transformer between the wall and your cell phone charger for "that extra protection"?

I don't use wall phone chargers at all, while in general my cell phone is powered from.... 12V car starter battery using 4.1V voltage regulator and... I didn't need charge this phone for a few months right now 
When I need make a call can connect it to any voltage source <25VDC including solar PV panels etc

[eneuro]

Just change the avrdude patch to time the page write commands instead of waiting for the ack.

Do you mean this AVR dude interface picoboot source?
https://github.com/nerdralph/picoboot/blob/master/avrdude/picoboot.c
or picoboot AVR dude configuration file ?
https://github.com/nerdralph/picoboot/blob/master/avrdude/avrdude.conf

Anyway, thanks for this link, while probably will be able write AVR dude extension for any bootloader right now 

Update: After review AVR dude picoboot extension code, I think that adding new

Code: [Select]

connection_type = light in AVR dude configuration file  could be nice feature to enable in a transparent way light based one way one direction MPU programming.

Possible entry formats are:
#
# connection_type = parallel | serial | usb

Than during opening simply check for light connection passed from AVRdude configuration file and adjust communication with light one way one direction bootloader .

Code: [Select]

static int picoboot_open(PROGRAMMER * pgm, char * port)
{
DEBUG("PICOBOOT: picoboot_open()\n");
strcpy(pgm->port, port);
// TODO: pgm->connection_type
// if (serial_open(port, pgm->baudrate? pgm->baudrate: 115200, &pgm->fd)==-1) {
// return -1;
}
return -1;
...
}
However, I might have other requirements in my bootloader and strong pasword protection is a must, not only for security reasons, but to be able do something similar to mentioned above: choose which AVR MPU will be programmed by setting passwords and device IDs than send light beam and let it choose correct MPU for reflashing, so at list some password protection is needed.
Additionally, not only full reflash mode might be needed, but changing part of MPU flash data and make at boot time checksums of whole flash for program integrity, so aging MPU with changed flash can be detected, so easy to detect any memory failures and in this case bootloader will stop running corrupted code, so probably I need glue a few small bootloaders together and make custom which will fit my requirements better, designed for those kind of projects.

[Psi]

I've made some programmable led ID tags that were reprogrammable from a light source.
You could change the display message by holding it to a PC/phone screen running some software.

It was only updating the eeprom not the actual code and at 60hz with manchester encoding you only get 30 bit per sec, far too slow for firmware.

To get around the one way comms issue i had it sending all packets in a loop and the ID tag would display the message once it got all packets correctly

[eneuro]

It was only updating the eeprom not the actual code and at 60hz with manchester encoding you only get 30 bit per sec, far too slow for firmware.

Thank you, I forgot about refresh rates, while was thinking about maybe even simplier aka Morse code encoding like this:

Code: [Select]

00000001110101011101010111010....1110100000000where I send one byte separeted each other by zeroes meaning also end of communication and bit one is represented by 3 times longer logical high (1) sequence, separated by low level (1/3 of the time on one ) and also bit 0 send as 1's but at 3 times shorter perdiod of time than bit one in this aka Morse code encoding 
This way at low speed it can be even redable by human, but probably due to this quite low refresh rates it might be real issue to flash AVR, because of Morse code will be of course much slower than in  manchester encoding you sugested, so yep it happends sometimes

However, when we assume ATTiny85 8KB flash program size, than....  we need send only 8192 bytes, which is ~81920 bits (assuming additional 2 bits in each byte for CRC) than at 30 bit/s... 45 minutes about  half hour without CRC in each byte, so not to practical sometimes, but well, not every AVR ATTiny MPU will use full 8KB program size and additionaly we do not have to do to much during such AVR light programing-can leave device and let it go, than only after succesfull reflash bootloader will allow MPU run this send code, in some cases maybe it could be acceptable in final product (not during development, but we can use in this case some simply PC interface at much higher speed, eg. diode connected to PCB USB port driven from PC software, etc).

Or send customer with our product small gadzet-LED PWM lamp connected to USB and tell him it can use this toy to reflash at much higher speeds.
So, I do not dismis this idea, we'll see what happends and how it will perform 

[ralphd]

If you want a secure password protection with one way communication, I think you'll have to use pki, which will add significant overhead to a bootloader.

[eneuro]

Strong passwords will be next step, now making software to connect from Linux using UCB to small ATTiny85 based PCB with white LED powered from USB to be able speed up AVR programming using light interface mentioned above 

Designing small PCB based on this schematics below from V-USB with ATtiny45 / ATtiny85 without a crystal, while succesfully compiled  sample code to toggle LED on this dongle of course without FTDI fake chips 



First have to ensure this thing above will not  my PC USB 
What do you think to add additional resistors betwen USB D+/D- pins and zeners 3V6?
Probably will use TL431I voltage reference to power up ATTiny 85 from this USB port and lower down voltage on ATTiny to 3.6V and drive LED from USB+5V using NPN transistor based on MPU outpin pin, while I do not like idea conect MPU directly to USB+5V?? without any voltage regulator.
Zeners probably not needed no more when I will lower down MPU voltage to 3.3V.
This will be proove of concept only, so do not care too much now about this quick PC USB to MPU hack with a few additional components.

Than will try  sample bootloaders source code (combine TSB with PICOBOOT to support AVR light programing interface...maybe with AVRDude support shown above...

[ralphd]

Its better to use a 3.3 or 3.6V supply rather than 5V with zeners.
http://nerdralph.blogspot.ca/2015/01/usb-interfacing-for-avr-microcontrollers.html

[eneuro]

Its better to use a 3.3 or 3.6V supply rather than 5V with zeners.

I have 3.44Vcc without any zeners, but problem is that firmware written for this V-USB from the link above probably expects (wants) 16MHz frequency, while they wrote something like this (this will work for sure on 5Vcc)

Fuse bits
Oh and one last thing – the fuse bits need of course be changed. Remove the 8x clock divider and switch to High Frequency PLL clock (CKSEL=0001) with slowly rising power (SUT=10). For ATtiny45/85 this should result in low fuse byte of 0xE1. You might also consider 2.7 V brown-out detection, making the high byte 0xDD:
avrdude -c usbtiny -p attiny85 -U lfuse:w:0xe1:m -U hfuse:w:0xdd:m
Those settings (required for oryginal code to work) leads to 16MHz system clock: 64MHz PLL divided by 4:


When we take into account clock frequency vs VCC: http://www.atmel.com/Images/Atmel-7669-ATtiny25-45-85-Appendix-B-Automotive-Specification-at-1.8V_Datasheet.pdf
than it looks like at Vcc between 3.3V - 3.6V we can have max 8MHz clock 


The same on those fugures: active current vs frequency:


So, probably sample oryginal source code included for V-USB implementation need to be changed, to support maximum 8MHz ATTiny  @ 3.44Vcc I have, while unsure if it will work without any tweaking oryginal MPU source code for V-USB

http://www.avrfreaks.net/forum/attiny-16mhz
Yep, they expect 16MHz MPU, so probably @ 3.44Vcc it is not possible, so that i swhy they uses USB 5V as VCC and 3.6V zeners, so probably description is wrong and oryginal included code  http://codeandlife.com/data/usb_tiny85_20120222.zip won't work at 3.3V since we have 8MHz max at this Vcc 

[ralphd]

While technically overclocked, all the AVR MCUs Ive used work fine at 16Mhz with a 3.3V supply.
If you are not comfortable with that, you could use the 12Mhz mode with the RC oscillator.  Tim documented how to do this on his blog cpldcpu.wordpress.com.

[ralphd]

Just looked at the tiny13a datasheet figure 19-2.  Its speced for up to 13Mhz at 3.3V.

[Marco]

If you want a secure password protection with one way communication, I think you'll have to use pki, which will add significant overhead to a bootloader.

The tiny is pretty much a lost cause at that point, NanoECC takes 6 kB.

[Psi]

One issue I had was the LCD backlight pwm which is usually 100 - 400hz
It gets in the way of the data. You need to do some analog filtering of the signal first. An envelope worked best for me

[eneuro]

If you want a secure password protection with one way communication, ...

Now, just trying to figureout what is going on in picoboot code and... realized that it uses serial port under AVRdude and USI serial on AVR?

In picoboot.S i looks like AVR RESET pin is used as boot pin?

Code: [Select]

/* PINB5 = Reset on ATtinyx5 */
#define BOOTPIN PINB5
Do I have to have Reset disabled, since there is something like this in this code, so to be able run this code with BOOTPIN=PINB5 (Reset pulled up to VCC via 10k most often) on ATTiny85, I have to disable reset pin or change this BOOTPIN for another one, I guess 

Code: [Select]

BootStart:
        ; sbi PORTB, BOOTPIN                            ; enable pullup
        sbic PINB, BOOTPIN                              ; run bootloader if BOOTPIN low
        rjmp AppStart                                   ; jump to application code
However, it looks like USI is used for serial communication, so I will have to completly change this code  as well as conditions when bootloader is activated -add password protection there 

Update: Nope, it is never easy decode assembler code especially, when Makefile is used and no clear inforamtion which assembler source files are compiled
In boot.S we have:

Code: [Select]

#define BOOTPIN PINB0so I do not know, but according to project description there: http://code.google.com/p/picoboot/

Code: [Select]

The bootloader is started when a serial idle signal is detected on the Rx pin (PB0 on the ATtiny84 and ATtiny85, PD0 on the ATtiny88).Probably PB0 is used for ATTiny85.

BTW: I've changed Makefile to use 1MHz clock and set device  as attiny85 .

I will try make a few changes to this software and we'll see what happends-it should now run on my ATTiny85 with current fuses  settings -1MHz clock by default changed to 8Mhz in main software

Still a long way to go for custom bootloader
How did you managed make it so small 

Code: [Select]

avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -Wl,-section-start=.bootloader=0x1fbe -o picobootSerial.elf picobootSerial.o
Its address in MPU flash memory 0x1FBE means on 8KB ATTiny85, that it i slocated at last... 8192?8126= 66 bytes? 

[eneuro]

Picoboot could work in a one-way mode...

OK, finally I've found that soft UART is used in picobootSerial.S

So, it looks like avrdude protocol is like described in picobootSerial.S header:

Code: [Select]

* The protocol is pairs of 4-byte frames:
 * data lo, data hi, FCS (EOR), command
 * data from the first frame is copied r0, r1.  For the next frame,
 * data is copied to Z, command is written to SPMCSR, followed
 * by the spm instruction. The command for the first fame must be 0.
However, since it looks like:

Code: [Select]

* bootloader acks to programmer with 0xC0 after each byteprobably I need remove this part of code in the case of my light interface (not serial) since I can't give any feedback to avrdude programmer and change avrdude config and recompile extension to be able in avrdude do not wait  for ack from bootloader

So, now I've created my custom bootloader code based on picobootSerial.S example and hopefully it compiles

Code: [Select]

$ make
avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -x assembler-with-cpp -c eneurobootlight.S -o eneurobootlight.o
avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -Wl,-section-start=.bootloader=0x1fbe -o eneurobootlight.elf eneurobootlight.o
avr-objcopy -O ihex eneurobootlight.elf eneurobootlight.hex
I need to change this code to read data bytes from PC avrdude custom extension in a diferent way just using one of AVR pins connected to photodiode and PC driving this photodiode using light and custom avrdude extension, since supported methods are PC ports parellel/serial/usb 

It will be fun to use laser light beam to reflash AVR ATTiny85 from quit elong distance  if I manage this changed code to work 

[eneuro]

Yep, succesfully added my new programer type eneurobootlight to avrdude version 6.1 in pgm_type.c and installed new version doesn't complain about my new programmer type:

Code: [Select]

$ avrdude -c eneurobootlight
avrdude: syntax error at /opt/avrdude-6.1-x64/etc/avrdude.conf:360
however it doesn't like my new connection type: light 
$ avrdude -c ?
avrdude: syntax error at /opt/avrdude-6.1-x64/etc/avrdude.conf:360

Code: [Select]

programmer
  id    = "eneurobootlight";
  desc  = "Eneuro boot light programmer";
  type  = "eneurobootlight";
  ###baudrate = 10000;    # 230400@8Mhz, 460800@16
  connection_type = light;
  ###connection_type = serial;
;

Update: Changed this connection type to: serial since despite it is light interface, still it is some kind of serial comunication, so that is fine-now recompiled avrdude nicely shows my new programmer: eneurobootlight 

Code: [Select]

$ avrdude -c ?
  ...
  eneurobootlight  = Eneuro boot light programmer
  ere-isp-avr      = ERE ISP-AVR <http://www.ere.co.th/download/sch050713.pdf>
  flip1            = FLIP USB DFU protocol version 1 (doc7618)
  flip2            = FLIP USB DFU protocol version 2 (AVR4023)
  frank-stk200     = Frank STK200
  ft232r           = FT232R Synchronous BitBang
  ft245r           = FT245R Synchronous BitBang
...
It does nothing for the moment since I have to implement this light avrdude interface, but it looks like I've properly setup avrdude for my new custom light programmer-there is no /dev/light device of course 

Code: [Select]

$ avrdude -c eneurobootlight -p t85 -P /dev/light

avrdude: TODO: IMPLEMENT LIGHT interface for port: /dev/light !!!

avrdude done.  Thank you.


[eneuro]

Tried implement dummy simulated flash write and log what avrdude tries to send to MPU using my custom eneurobootlight programmer:

Code: [Select]

$avrdude -v -v -c eneurobootlight -p attiny85 -P screen -U flash:w:attiny85-light-test.hex
and avrdude says among other stuff to check connections 
...
Double check connections and try again, or use -F to override
         this check.
...
Unfortunatelly, there will be no eelctric connection at all 

Code: [Select]

Programmer Type : eneurobootlight
         Description     : Eneuro boot light programmer
avrdude: programmer operation not supported

ENEUROBOOTLIGHT: eneurobootlight_not_implemented_1()
ENEUROBOOTLIGHT: eneurobootlight_initialize()
ENEUROBOOTLIGHT: eneurobootlight_send_frame()
ENEUROBOOTLIGHT: eneurobootlight_send_frame()

avrdude: frame bytes:  0x00 0x00 0x00 0x00

avrdude: eneurobootlight_send_frame(): (a) protocol error, expect ACK=0xc0c0c0c0, resp=0x00000000
avrdude: initialization failed, rc=-2
         Double check connections and try again, or use -F to override
         this check.

avrdude: programmer operation not supported
ENEUROBOOTLIGHT: eneurobootlight_close()

avrdude: close: port: screen

avrdude done.  Thank you.
I need to make happy avrdude  that it will never get what expects from MPU, especially ACK 

[eneuro]

Now much better -avrdude return of course fake hardcoded device signature since we can't read anything from MPU and attempt to verify written bytes fails, but that is fine for the moment

Code: [Select]

$ avrdude -c eneurobootlight -p attiny85 -P screen -U flash:w:attiny85-light-test.hex
avrdude: open: port: screen  baudrate: 10000

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e2a00
avrdude: programmer operation not supported
avrdude: programmer operation not supported
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "attiny85-light-test.hex"
avrdude: input file attiny85-light-test.hex auto detected as Intel Hex
avrdude: writing flash (334 bytes):

Writing | ################################################## | 100% 0.19s

avrdude: 334 bytes of flash written
avrdude: verifying flash memory against attiny85-light-test.hex:
avrdude: load data flash data from input file attiny85-light-test.hex:
avrdude: input file attiny85-light-test.hex auto detected as Intel Hex
avrdude: input file attiny85-light-test.hex contains 334 bytes
avrdude: reading on-chip flash data:

Reading | avrdude: programmer operation not supported
avr_read(): error reading address 0x0000
    read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2
avrdude: programmer operation not supported

avrdude: close: port: screen

avrdude done.  Thank you.
We were able to log all bytes send to bootloader in 64 bytes pages (flash writes )which is nice-it will help debug AVR bootloader assembler code

Code: [Select]

avrdude: eneurobootlight: frame bytes:  0x00 0x00 0x00 0x00

avrdude: eneurobootlight: paged write: address: 0x0000  bytes: 64
avrdude: eneurobootlight: frame bytes:  0xDF 0xCF 0x10 0x00
avrdude: eneurobootlight: frame bytes:  0x00 0x00 0x01 0x01
avrdude: eneurobootlight: frame bytes:  0x28 0xC0 0xE8 0x00
avrdude: eneurobootlight: frame bytes:  0x02 0x00 0x03 0x01
avrdude: eneurobootlight: frame bytes:  0x27 0xC0 0xE7 0x00
avrdude: eneurobootlight: frame bytes:  0x04 0x00 0x05 0x01
avrdude: eneurobootlight: frame bytes:  0x26 0xC0 0xE6 0x00
...
avrdude: eneurobootlight: frame bytes:  0x00 0x00 0x03 0x03
avrdude: eneurobootlight: frame bytes:  0x00 0x00 0x05 0x05
avrdude: eneurobootlight: paged write: address: 0x0040  bytes: 64
avrdude: eneurobootlight: frame bytes:  0x10 0xE0 0xF0 0x00
avrdude: eneurobootlight: frame bytes:  0x40 0x00 0x41 0x01
...
avrdude: eneurobootlight: frame bytes:  0x00 0x01 0x02 0x03
avrdude: eneurobootlight: frame bytes:  0x00 0x01 0x04 0x05
avrdude: eneurobootlight: paged write: address: 0x0140  bytes: 64
avrdude: eneurobootlight: frame bytes:  0x46 0x55 0x13 0x00
...
avrdude: eneurobootlight: frame bytes:  0xFF 0xFF 0x00 0x00
avrdude: eneurobootlight: frame bytes:  0x7E 0x01 0x7E 0x01
avrdude: eneurobootlight: frame bytes:  0x40 0x01 0x42 0x03
avrdude: eneurobootlight: frame bytes:  0x40 0x01 0x44 0x05

That is interesting-to program 334 bytes of flash, it looks like we need send ~4.75 ~5 times more bytes to bootloader

Code: [Select]

avrdude: close: port: screen  bytes: send: 1588it can be killer and in practice it will be difficult send all AVR MPU code using LCD screen light flashes, but it will depend on application and sometimes we'll let enduser apply only patches to configuration data, not code itself, so amount of data can be low

Anyway, time to change AVR bootloader itself and let it talk with LCD screen or other light source on one MPU pin using some kind of light sensor
It could be perfect have on this pin LED as output as well as light sensing, so lets try design such tricky circuit and implement it in new bootloader assembler code...

[eneuro]

There is some progress, but yep I had to look again and again into AVR assembler RJMP instruction description http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_RJMP.htm while I had to write small disassembly utility to be able understad this hardcoded RJMP statements in example picoboot avrdude implementation 

Code: [Select]

avrdude: eneurobootlight: flash address: oryginal appstart: 0xC00E  changed appstart: 0xCFEE  reset vector: 0xCFDF  virtual reset vector addr: 0x1FC0
avrdude: eneurobootlight: paged write: page: 0  address: 0x0000  bytes: 64

avrdude: eneurobootlight: frame bytes:  0xDF 0xCF 0x10 0x00  flash data: 0xCFDF
avrdude: eneurobootlight: frame bytes:  0x00 0x00 0x01 0x01  flash addr: 0x0000
Compiled sample AVR code (classic Hello AVR I'd like to use to test bootloader-diode blinking on PB1 ATTiny85 pin ay 1Hz at 8MHz clock) created code like shown above for first flash page, where at address 0x0000 reset vector was: 0xC00E, which means (thanks to disassemblers and Atmel AVR instruction set documentation linked above):

Code: [Select]

$ avr-rjmp  0xC00E
AVR assembler RJMP code: 0xC00E  rjmp: +0x001E (+28)So, nothing fancy- so far so good-classic AVR MPU code-oryginal reset verctor jumps somwhere to main program as RJMP instruction is: 0xC00E decoded above.

However, as we can see by analysis of what picoboot does the trick and change this oryginal restet vector during avrdude programming to point to his own code, but... lets see what we get when we'll try disassemble this 

It changes this application reset vector code from oryginal 0xC00E, to... 0xCFDF, which means:

Code: [Select]

$ avr-rjmp  0xCFDF
AVR assembler RJMP code: 0xCFDF  rjmp: -0x0040 (-66)
Yes, jump 66 bytes back, but... we are at first flash program memory adress 0x0000 

We know from bootloader complation that bootloader code is placed at adress 0x1FBE

Code: [Select]

avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -x assembler-with-cpp -c eneurobootlight.S -o eneurobootlight.o
avr-gcc -mmcu=attiny85 -DF_CPU=1000000 -nostdlib -Wl,-section-start=.bootloader=0x1fbe -o eneurobootlight.elf eneurobootlight.o
So, it puzzled me for a few hours  this RJMP -66 means and why someone hardcoded it as 0xCFDF in avrdude interface code? 

Code: [Select]

const uint8_t reset_vec_lo = 0xdf;   /* rjmp BootStart */
const uint8_t reset_vec_hi = 0xcf;   /* rjmp BootStart */

Hopefully, I realized that, since ATTiny85 has 8KB flash program memory, so it is: 8120 bytes, which in hex is: 0x2000,
so when we apply this strange 0xCFDF (RJMP -66)  instruction send by avrdude, which means that from address where it starts we need substract -0x0040 , we get: 0x2000 -0x0040=  0x1FC0 , so very close to place where our bootloader is already programmed in MPU: 0x1FBE .
How close is it?
Two bytes before place where new reset vector RJMP redirects us after succesfull MPU programming:
0x1FC0 = 0x1FBE +2  (rjmp)

So, now this part of bootloader code explains everything:  VirtualReset is at adress: 0x1FBE and BootStart: at 0x1FC0, since  instruction:
rjmp BlinkLED
is exactly 2 bytes in flash program memory and is replaced by bootloader with uploaded application during avrdude programming 

Code: [Select]

.section .bootloader,"ax",@progbits
VirtualReset:
    rjmp BlinkLED                   ; will be overwritten by programmer
BootStart:
    sbis UART_Port-2, UART_Rx       ; Rx high = start bootloader
    rjmp VirtualReset               ; jump to application code
    clr FCS
    sbi UART_Port-1, UART_Tx        ; set Tx pin to output mode

    ; continuous loop for commands from programmer
    ; when upload is finished, programmer resets chip & starts app
So, sick-it remainds me LOGO programming on Commodore64 by... writting directly into its RAM assembler code and this is exactly what is done during avrdude flash programming, where modified RJMP instruction is calculated 

Code: [Select]

/* calculate new rjmp for appstart */
    vrst_vec_addr = m->size - BOOTLOADER_SIZE;
    appstart = 0xc000 |
               ( (vrst_vec_addr/2) + (appstart & 0x0FFF) );
Unfortunatelly, 0xC000 is hardcoded in this sample picoboot code, so... it is not clear that it is part of RJMP binary two byte code   


Now, it should be easy change bootloader code, since we know howto calculate new bootloader position and.. howto (hard)code this new reset vector code in the case bootloader size will change if we have other requirements too.

BTW: If someone found this information usefull in his custom avrdude based bootloader project, feel free to... donate fraction of bitcoin at one of my Bitcoin adresses below, since I need to take a deep breath and  after this picoboot code investigation, so it probably can save someone a lot of time 

[ralphd]

You're doing pretty good.  I know the comments I write are good enough so I can understand the code when I go back to it, but it is nice to know others can figure it out too. :-)

For the ack handling in the avrdude code, you'll need to substitute a delay of 5ms after the page erase and page write commands.

[eneuro]

For the ack handling in the avrdude code, you'll need to substitute a delay of 5ms after the page erase and page write commands.

Copy that
Any hints helpfull since  it is never easy create byte opcode for microcontrolers and guess what MPu opcode does

However, I'm more concerned about another issue I think I've found 
I mean, when I've made analysis of flash program commands send to MPU during bootloader programming, it looks like bootloader RJMP to application code is not overwritten, so after flashing uploaded program using modified avrdude with oryginal picoboot MPU will still have such RJMP instead of new calculated 

Code: [Select]

0001fb0: ffff ffff ffff ffff ffff ffff ffff 21c0  ..............!.ootloader Even worse, when we disassemble this RJMP opcode at 0x1FBE flash byte address (first instruction in our bootloader) we have there still 0x21C0 RJMP:

Code: [Select]

$ ./avr-rjmp 0xC021
AVR assembler RJMP code: 0xC021  rjmp: +0x0044 (+66)which means that it will RJMP MPU NOT to uploaded app oryginal reset vector at 0x0000 in oryginal HEX (bin) app program code, but to... flash byte address 0x0002 and this is not what many applications will like, since this is.... INT0 interrupt on ATTiny85 as I know 

Reset vector is overwtitten with bootloader to RJMP to 0x1FC0, but at 0x0002 uploaded app program will find interupt vectors NOT oryginal app start code, I think 

Code: [Select]

0000000: dfcf ffff ffff ffff ffff ffff ffff ffff  ................
0000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................

Below is why RJMP will go there (disassembler also shows 0x2002 RJMP there)
RJMP: 0xC021 :   0x2000 +0x0044= 0x2002, flash size is 0x2000 in hex, so we land at 0x0002 flash byte-no supprise since this is place where BlinkLED: is in picobootSerial.S code:

Code: [Select]

.text
    rjmp BootStart
BlinkLED:
    sbi DDRB, LEDPIN
Blink:
    sbi PINB, LEDPIN
    ldi ZH, 30
DelayLoop:

Unfortunatelly, what I mean-it looks like this VirtualReset: RJMP is updated in avrdude picoboot and marked (taggled), but... no flash programming code send to AVR MPU -so trying to fix this by add needed flash command for page before where bootloader is installed 

Code: [Select]

.section .bootloader,"ax",@progbits
VirtualReset:
    rjmp BlinkLED                   ; will be overwritten by programmer

BTW: I think, that oryginal blink.S  diode blink app demo for bootloader has no chance to work with oryginal picobootSerial.S, because of avrdude picoboot programmer will write in the place where ledblink pin is set as output at 0x0000 flash program memory byte-will overwrite with AVR opcode:
0xCFDF  rjmp to bootloader BOOTSTART:
, so adding nop fixes this as shown below-else

Code: [Select]

sbi DDRB, LEDPIN will be replaced with 0xCFDF 

Code: [Select]

.text
    nop
LedOutput:
    sbi DDRB, LEDPIN
Blink:
    sbi PINB, LEDPIN
    ldi ZH, 40