Bootloader encriptado para Attiny88

[Picuino]

El problema era el shift a derechas del asm.

No creas, todavía tengo para rato.

Tengo que implementar el protocolo. Acabo de ponerle un checksum fletcher para comprobar que los datos cifrados se han recibido ok.
Si todo está bien, a continuación se desencripta y graba los datos en flash.
Por último, todos los datos de la flash menos el bootloader deben tener un checksum determinado antes de saltar a la dirección de inicio.

Además el bootloader tiene que esperar un tiempo en el inicio, para recibir datos. Si no recibe datos, salta a la aplicación.

El vector de reset está siempre fijo apuntando al bootloader, de manera que el vector de reset recibido hay que desplazarle (otro problema más)

Todas las pruebas las hago en c que es más flexible y rápido. Por último tengo que pasar todo a ensamblador y minimizar el tamaño.


Saludos.

[KILLERJC]

El vector de reset está siempre fijo apuntando al bootloader, de manera que el vector de reset recibido hay que desplazarle (otro problema más)

Eso estaba pensando, si lo pones al final al codigo para que te permita cambiar los vectores, te vas a tener que asegurar que el vector de reset no lo cambie nunca .

[Picuino]

Si. Es una medida de seguridad. Igual que comprobar que el bootloader no se sobreescribe.

He hecho medidas de tiempo y tarda unos 7700 ciclos en desencriptar 8 bytes (0.96 ms)
En total cada página de memoria de 64 bytes tardará:

   6.1ms  recepción por UART de 70bytes (datos + checksum + dirección) a 115200 baud
   7.7ms desencriptado
   4ms en borrar memoria (cpu halted)
   4ms en escribir memoria (cpu halted)
   0.01 ms enviar acknowledge
   0.01 ms otras rutinas (checksum, ...)

Total = 22 ms para grabar una página de 64 bytes.

Unos 2.7 segundos para grabar toda la flash de 8kbytes.

Es suficiente.

[Picuino]

He tenido algún problema de corrupción de datos trabajando a la vez con c y con assembler.

Atmel recomienda que las variables se declaren en C y que se enlacen en assembler.

Ejemplo C:

Código: C

1. char buff_reg[32];
2.  
3. int main(void) {
4. ...

Ejemplo ASM:

Código: C

1. .data
2. .extern    buff_reg
3.  
4. .text
5. ; inicio de las rutinas

Un saludo.

[Picuino]

Cuento los avances.

Estos días he estado pensando en una rutina para entrar en el bootloader.
Tenía que cumplir muchas condiciones y no era sencillo:

1. Las líneas de comunicación del bootloader son serie (UART) y comparten pines con el interface I2C.
2. Durante el reset, puede que el maestro I2C esté enviando datos a 100kbaud y hay que evitar que eso haga entrar al bootloader.
3. El bootloader quiero que funcione desde un conversor USB-RS232 o desde un Arduino. Esto significa que todas las señales que le llegan al bootloader tienen que mantener un estandar de tiempos RS232
4. La codición de entrada al bootloader tiene que ser robusta, pero al mismo tiempo que no se pueda entrar en modo bootloader de forma accidental.
5. La rutina que detecte la condición de entrada al bootloader debe ser sencilla de implementar, que ocupe poco código.

Después de darle muchas vueltas llegué a la conclusión de que lo mejor era entrar en el bootloader si se daba la condición de un pulso de nivel bajo de un tiempo determinado durante los dos primeros segundos después del reset:

  --------|             |-------
          |-------------|

Pensé que el pulso podía ser de 15 milisegundos a nivel bajo.
De esta forma se puede crear con un conversor USB-UART simplemente enviando un cero a 600 baudios.
Este tiempo es relativamente grande y no se va a confundir con un pulso de I2C.
Por otro lado, suponiendo que haya ruido en la patilla de entrada, es difícil que aparezca un pulso negativo de exactamente 15ms.
Es un tiempo demasiado alto para un espúreo y lejos de los 10ms de la frecuencia de red.

He programado ya una rutina y ensambla sin errores:

Código: [Seleccionar]

;
; Comprueba durante 2 segundos si hay un pulso bajo de 15 milisegundos.
; Si se cumple la condición, entrar en el bootloader
;
#define counter        r24
#define counter_hi     r25
#define cycles         r26
#define pulse_time     r27

#define BOOT_PULSE_WAIT_MS    2000
#define BOOT_PULSE_MS           15
#define BOOT_PULSE_COUNTER    ((BOOT_PULSE_WAIT_MS * 250) / BOOT_PULSE_MS)
#define DELAY_3CY_COUNTER     (((BOOT_PULSE_MS*8000/250)-15)/3)

boot_pulse:
   ldi   counter, lo8(BOOT_PULSE_COUNTER)
   ldi   counter_hi, hi8(BOOT_PULSE_COUNTER)
   clr   pulse_time                ; uint8_t pulse_time = 0

boot_pulse_loop:                   ; DO {
   ldi   cycles, DELAY_3CY_COUNTER ;    delay_us(60)  (480-15 cycles)
   rcall Delay3Cycle               ;

   sbic  UART_PIN, UART_RX         ;    IF (RX == LOW):  (5cy)
   rjmp  boot_pulse_high           ;
   inc   pulse_time                ;       pulse_time++
   rjmp  boot_pulse_2              ;
boot_pulse_high:                   ;    ELSE:  (6cy)
   cpi   pulse_time, 245           ;       IF (pulse_time > 245*delay_us && pulse_time < 256*delay_us):
   brsh  bootloader                ;          GOTO bootloader
   clr   pulse_time                ;       pulse_time = 0;

boot_pulse_2:
   sbiw   counter, 1               ;    counter--;  (4cy)
   brne   boot_pulse_loop          ; } WHILE(counter)

   rjmp   run_user_program         ; GOTO run_user_program

Esta rutina mejora mucho en tamaño a que hice ayer. Ocupa 30bytes (15 instrucciones)

Ahora sólo falta hacer pruebas.

Un saludo.

[KILLERJC]

Tengo mis ciertas dudas del programa....

Como que ocurra el envio en un punto en que el contador ya esta terminandose, supongamos que en esos 2 segundos  se envie a los 1.99s  dejandote 10ms. Es lo unico que veo que puede fallar.

Por que me preocupa esto? Por que es una comunicacion RS232 y no sabes cuando se reseteo el micro, prefiero mil veces un boton el cual tenes un "control" de cuando vas a entrar al modo bootloader.
Tampoco podes enviar nada indicando del reset por que sos un esclavo para el I2C. Y tenes que asegurarte de que no va a ocurrir con el I2C eso de mantenerlo por 15ms. Como por ejemplo que las resistencias de pull.up lo tenga la otra placa, y al alimentar la placa con el micro y el bootloader no tenga nada que lo este pulleando a VCC.

Creo que podrias achicar un poco mas el programa con un cambio, no es mucho creo que son 2 instrucciones., pero nuevamente hay que ver los ciclos de las intrucciones.

Código: ASM

1. boot_pulse:
2.    ldi   counter, lo8(BOOT_PULSE_COUNTER)
3.    ldi   counter_hi, hi8(BOOT_PULSE_COUNTER)
4.    clr   pulse_time                ;
5.  
6. boot_pulse_loop:                   ;
7.    ldi   cycles, DELAY_3CY_COUNTER ;
8.    rcall Delay3Cycle               ; ???? Donde esta esa funcion ? ademas rcall lleva 3 ciclos tinyAVR + 4 del return y te llenaria el STACK si no usas un return.
9.  
10.    sbis  UART_PIN, UART_RX         ;
11.    rjmp  boot_pulse_2              ;
12. boot_pulse_high:                   ;
13.    cpi   pulse_time, 246           ; Incremento en 1 por el efecto del inc pulse_time de abajo
14.    brsh  bootloader                ;
15.    clr   pulse_time                ;
16.  
17. boot_pulse_2:
18.    inc   pulse_time                ;
19.    sbiw   counter, 1               ;
20.    brne   boot_pulse_loop          ;
21.  
22.    rjmp   run_user_program         ; GOTO run_user_program

[Picuino]

Gracias por el código, Killer.

Tengo mis ciertas dudas del programa....

Como que ocurra el envio en un punto en que el contador ya esta terminandose, supongamos que en esos 2 segundos  se envie a los 1.99s  dejandote 10ms. Es lo unico que veo que puede fallar.

No es un problema, sólo un límite de tiempo. Eso se puede cambiar en el programa para ampliarlo hasta 4 segundos.

Por que me preocupa esto? Por que es una comunicacion RS232 y no sabes cuando se reseteo el micro, prefiero mil veces un boton el cual tenes un "control" de cuando vas a entrar al modo bootloader.

Tengo botones, pero no quiero utilizarlos. La placa está destinada a usuarios sin conocimientos. Si aprietan el botón por error, va a entrar el bootloader y pensarán que la placa no funciona. No quiero que dé esa impresión.

El pulso debe tener exactamente 15 milisegundos. No funciona con 14ms y tampoco con 16ms.
Si se lleva a Vcc no hay problema (no hay pulso). Si se lleva a GND no hay problema (el pulso es mayor de 15ms).
Es una condición muy difícil de cumplir por error.

Por otro lado es una condición muy sencilla de cumplir para el programa que carga el bootloader desde el PC.

Tampoco podes enviar nada indicando del reset por que sos un esclavo para el I2C. Y tenes que asegurarte de que no va a ocurrir con el I2C eso de mantenerlo por 15ms. Como por ejemplo que las resistencias de pull.up lo tenga la otra placa, y al alimentar la placa con el micro y el bootloader no tenga nada que lo este pulleando a VCC.

Sí que puedo enviar datos de vuelta. De hecho las líneas funcionan como RS232 en modo bootloader (con TX y RX) y funcionan en modo I2C el resto del tiempo.
Esa es otra razón por la que quiero evitar que la placa entre en modo bootloader así como así. Sólo debe hacerlo cuando realmente sea necesario.

En cuanto al I2C, es muy difícil que a 100kbaud vaya a generar un pulso bajo de exactamente 15ms, ni más ni menos.

Creo que podrias achicar un poco mas el programa con un cambio, no es mucho creo que son 2 instrucciones., pero nuevamente hay que ver los ciclos de las intrucciones.

Código: ASM

1. boot_pulse:
2.    ldi   counter, lo8(BOOT_PULSE_COUNTER)
3.    ldi   counter_hi, hi8(BOOT_PULSE_COUNTER)
4.    clr   pulse_time                ;
5.  
6. boot_pulse_loop:                   ;
7.    ldi   cycles, DELAY_3CY_COUNTER ;
8.    rcall Delay3Cycle               ; ???? Donde esta esa funcion ? ademas rcall lleva 3 ciclos tinyAVR + 4 del return y te llenaria el STACK si no usas un return.
9.  
10.    sbis  UART_PIN, UART_RX         ;
11.    rjmp  boot_pulse_2              ;
12. boot_pulse_high:                   ;
13.    cpi   pulse_time, 246           ; Incremento en 1 por el efecto del inc pulse_time de abajo
14.    brsh  bootloader                ;
15.    clr   pulse_time                ;
16.  
17. boot_pulse_2:
18.    inc   pulse_time                ;
19.    sbiw   counter, 1               ;
20.    brne   boot_pulse_loop          ;
21.  
22.    rjmp   run_user_program         ; GOTO run_user_program

Ese programa salta al bootloader si el pulso es mayor de 15ms (esto quiero evitarlo, como he comentado antes)

El código que falta es sencillo:

Código: [Seleccionar]

Delay3Cycle:
   subi  cycles, 1
   brne  Delay3Cycle
   ret

[Picuino]

Uno de los problemas que tengo consiste en que el oscilador interno debe estar muy bien calibrado para que todo funcione.
El programa tiene una tolerancia desde 14.7ms hasta 15.3ms (+-2%)

Esto es aceptable cuando se trabaja con osciladores a cristal, pero el oscilador interno del Attiny tiene una tolerancia inicial del 10%.
Sólo si se calibra, se consigue una tolerancia del 1% en frecuencia.

Hay dos soluciones:
1. Calibrar el oscilador en el bootloader: Es complejo y engorroso. Se puede hacer por medio de la EEPROM, pero alarga el programa y no es muy seguro.

2. Enviar pulsos de diferentes tiempos, 13.5ms, 14ms, 14.5ms,, 15ms, 15.5ms, 16ms, 16.5ms
    Esto se puede hacer sin problema con el Arduino, pero no sé si se puede calibrar con tanta exactitud un USB-UART
    Otro problema es que algunos de estos pulsos se van a interpretar como si fuesen datos por parte del Bootloader Attiny y pueden desincronizar la transmisión de datos UART.

Un saludo.

[KILLERJC]

Ese programa salta al bootloader si el pulso es mayor de 15ms (esto quiero evitarlo, como he comentado antes)

Tu programa estaba igual comparaba de 245-255, en mi caso era igual. Y para arreglarlo dejarlo como queres, podes comparar cuando se terminan los 2 segundos. si esta dentro de un rango (que es lo que deberias hacer) entonces  continuas con el bootloader.
El mayor problema que encuentro es que trabajamos en 8 bits, y un overflow de por asi decirlo 510 ( 256 -250 ) seria valido.

Codigo (no lo expuesto antes):

Código: ASM

1. ; Caso que solo se admita un solo pulso en esos 2 segundos, solo se tomara en cuenta el ultimo, espera todos lso 2 segundos para saber si entro o no al bootloader
2.  
3.  
4. #define         PULSE_MIN       245
5. #define         PULSE_MAX       250
6.  
7. boot_pulse:
8.         ldi   counter, lo8(BOOT_PULSE_COUNTER)
9.         ldi   counter_hi, hi8(BOOT_PULSE_COUNTER)
10.         clr   pulse_time                ;
11.      
12. boot_pulse_loop:                        ;
13.         ld      cycles, DELAY_3CY_COUNTER ;
14.         rcall   Delay3Cycle               ;
15.      
16.         sbis    UART_PIN, UART_RX       ;
17.         rjmp    boot_pulse_low          ;
18.         set                             ; T indica que la señal subio, si llega a bajar y esta seteado entonces procedo a borrarlo
19.         rjmp    boot_loop_end           ; Subio asi que voy a preguntar de nuevo por la entrada
20. boot_pulse_low:                         ; Caso que estuviera bajo
21.         brtc    boot_pulse_low2         ; Esta seteado T? subio y bajo ? Aca me quedan 2 opciones mantener el mayor ocupo 2 registros o borro todo
22.         clr     pulse_time              ; Borro en este caso
23. boot_pulse_low2:
24.         inc     pulse_time              ; Incremento debido a que paso 1, a pesar de que subio y bajo.
25. boot_loop_end:
26.         sbiw    counter, 1              ;
27.         brne    boot_pulse_loop         ;
28.  
29.         cpi     pulse_time, PULSE_MIN   ;
30.         brlo    run_user_program        ;
31.         cpi     pulse_time, PULSE_MAX   ;
32.         brsh    run_user_program
33.         rjmp    bootloader              ; GOTO bootloader
34.  
35.  
36.  
37. ; Caso que solo el primer pulso entre y cumpla las condiciones entre a modo bootloader sin tener que esperar los 2 segundos
38.  
39.  
40. #define         PULSE_MIN       245
41. #define         PULSE_MAX       250
42.  
43. boot_pulse:
44.         ldi   counter, lo8(BOOT_PULSE_COUNTER)
45.         ldi   counter_hi, hi8(BOOT_PULSE_COUNTER)
46.         clr   pulse_time                ;
47.      
48. boot_pulse_loop:                        ;
49.         ld      cycles, DELAY_3CY_COUNTER ;
50.         rcall   Delay3Cycle               ;
51.      
52.         sbis    UART_PIN, UART_RX       ;
53.         rjmp    boot_pulse_low          ;
54.         set                             ; T indica que la señal subio, si llega a bajar y esta seteado entonces procedo a borrarlo
55.         cpi     pulse_time, PULSE_MIN   ; Si subio puede indicar 2 casos, 1ero que estaba arriba, lo cual no va a incrementar en nada pulse_time
56.         brlo    boot_loop_end           ; 2do, que estaba en 0 y paso a 1, en ese caso va a tener un valor pulse_time y se va a comparar
57.         cpi     pulse_time, PULSE_MAX   ; si estaba fuera de rango, entonces va a continuar. Si llega un 0 se resetea pulse_time,
58.         brsh    boot_loop_end          
59.         rjmp    bootloader              ; Caso que estuviera dentro de los valores
60. boot_pulse_low:                         ; Caso que estuviera bajo
61.         brtc    boot_pulse_low2         ; Esta seteado T? subio y bajo ? Aca me quedan 2 opciones mantener el mayor ocupo 2 registros o borro todo
62.         clr     pulse_time              ; Borro en este caso
63. boot_pulse_low2:
64.         inc     pulse_time              ; Incremento debido a que paso 1, a pesar de que subio y bajo.
65. boot_loop_end:
66.         sbiw    counter, 1              ;
67.         brne    boot_pulse_loop         ;
68.  
69.         rjmp    run_user_program        ; GOTO programa de usuario

Deje 2 codigos, hay un comentario arriba de cada codigo, utilize bastantes banderas por que no se si hay un equivalente a la direccion actual del PC en ese momento tal como hay en MPASM del PIC ( $ ).
Y tambien me excedi en el programa. todo depende exactamente como es que queres que funcione. Podria haber comparado nomas con 1 valor y luego usart T en caso de un overflow.

Mi otra pregunta, no posee un cristal tu placa? Uno de 32k ? como para un reloj ?

2. Enviar pulsos de diferentes tiempos, 13.5ms, 14ms, 14.5ms,, 15ms, 15.5ms, 16ms, 16.5ms
    Esto se puede hacer sin problema con el Arduino, pero no sé si se puede calibrar con tanta exactitud un USB-UART
    Otro problema es que algunos de estos pulsos se van a interpretar como si fuesen datos por parte del Bootloader Attiny y pueden desincronizar la transmisión de datos UART.

Pero cuando cambien las condiciones de temperatura se perdio todo lo bueno de eso. Ademas seria un valor inicial y nunca mas tocarlo. es decir una calibracion en la "fabrica". Sino implementarlo en el micro si va a ser un dolor de cabeza. Como discriminas que esos pulsos no sean de otra cosa ?

Tengo botones, pero no quiero utilizarlos. La placa está destinada a usuarios sin conocimientos. Si aprietan el botón por error, va a entrar el bootloader y pensarán que la placa no funciona. No quiero que dé esa impresión.

Si tiene 3/4 botones, tenerlos presionados a todos por 2/4 segundos en el reset no es ningun error. O peor aun si pensas que sea 2 botones por mas tiempo.
Lo bueno de esto es que si se suelta ya no entra mas a modo bootloader.

[Picuino]

Si, en mi programa puede haber desbordamiento del contador.

En ese caso sólo se salta al bootloader si el contador está entre 245 y 255 (10 valores de 255)
Esto se cumplirá en 15ms +- 0.3ms y en 30.3ms +-3ms y en 45.6ms +-3ms  etc, etc.

En cualquier caso un pulso aleatorio sólo tendrá una probabilidad del 4% de colarse como bootloader.


La placa no posee cristal. Como dices, una calibración "de fábrica" tiene muchos problemas. Por eso pensaba en enviar un tren de pulsos de diferentes tamaños. Así alguno conseguirá iniciar el bootloader.

Lo de los botones también lo había pensado. En la placa hay 6. En este caso me parece un poco engorroso andar apretando un monton de pulsadores con una mano mientras con la otra se resetea (o se conecta Vcc). Lo veo engorroso para el usuario. Nunca me gustó lo del Ctrl+Alt+Supr. El que no lea el manual (más de la mitad del mundo) no conseguirá actualizar el firmware.
Un usuario inexperto es algo de otro mundo. Cualquiera que haya estado en un servicio de atención al cliente lo ha vivido de cerca.



Un saludo.

[Picuino]

Voy a leer el nuevo código más despacio.

[Picuino]

Hay otra posibilidad que no me terminaba de gustar:

Que la aplicación de usuario entre en el bootloader. No me parece elegante. Esto implica que debe haber una aplicación de usuario desde el comienzo.

Como la aplicación de usuario es siempre mía, yo puedo controlarla. Pero no me gusta depender de ella. Si en algún momento se corrompe, adiós bootloader también.

Sí que se podría utilizar como una opción más  (no la única).

De esta forma, puedo enviar una orden I2C para que la placa entre en modo bootloader. Se elimina la necesidad de quitar corriente o de resetear la placa. Es todavía más elegante.

El problema es que no puedo depender siempre de este método, pero es un buen complemento al otro.

Un saludo.

[Picuino]

Hay una cosa que no entiendo del linker.

He hecho este programa:

Código: [Seleccionar]

.text
.global main
main:
   rjmp  main
Sólo tiene una instrucción y compilado ocupa 64 bytes ????

Los 40 bytes iniciales son los vectores de interrupción, pero ¿que pasa con los otros 24?
Aquí no hay que inicializar variables ni nada.

¿Cómo puedo quitar el enlace al CRT0 y dejar el código sin más?

[KILLERJC]

No hay que inicializar variables con lo que las variables no ocupan espacio, pero el CRTO0/1 si lo hace, y lo tenes siempre.

¿Cómo puedo quitar el enlace al CRT0 y dejar el código sin más?

Deja de compilarlo con el de C y hace un ASM solo. Haces todo el bootloader en ASM, y luego cuando terminas si llamas al crt0 de tu programa.
O fijate si encontras una opcion para el gcc para indicarle que no lo agregue a ese startup.

[Picuino]

Ya tengo todo en asm. Pero sigue linkando el crt0.
No encuentro la opción para eliminarlo. Utilizo las mismas opciones del picoboot (que no tiene crt0) pero a mí sí me lo añade.
No consigo eliminarlo.

Voy a leer esto que promete:
Compiling assembler files with avr-gcc without C runtime
http://quanttype.net/posts/2014-01-27-avr-gcc-assembler.html