Go Down

Topic: Bootloader for Tiny chips? (Read 2 times) previous topic - next topic

Tom Carpenter

Does anyone know if there is an arduino compatible bootloader around for the ATTiny84?

I want to use the RESET pin as an extra I/O pin, but cant do this without a bootloader. Doing so disables the ability for it to be programmed via SPI, and as such would require an high voltage programmer to make any changes. By adding a bootloader, the reset pin would become unnecessary (I can just reset the power to the tiny chip just before the download starts).

I don't mind modifying a bootloader to suit the chip, the issue is finding one which can reside in normal programming memory as the ATTiny's dont have a NWWR bootloader section which throws optiboot out of the equation as far as I can tell.

Thanks.
~Tom~

spycatcher2k

The attinys don't tend to have/suppot UART so I think it may not be possible.
Drew.
http://www.uk-pcb.co.uk - My UK Based PCB Fab & Assembly Company
Design work undertaken
SMD & Thru-Hole assembly

Tom Carpenter

I was thinking of using a software based UART, I know Optiboot has one for the slower baud rates. I could also possibly use the USI module configured as I2C and use another arduino as a USB-I2C adapter.

I was mainly hoping that someone has already come up with a way to use the ATTiny's self programming mode.
~Tom~

Tom Carpenter

Well that shows how much attention I was paying to the code. Apparently, optiboot already supports the Attiny84 (luminet) chip. I'm sure I read somewhere that it didn't work with virtual boot partitions...

:smiley-red:.
~Tom~

Coding Badly


Bear in mind that, as far as I know, no one has had success with Optiboot on an ATtiny84 processor.  A few folks have tried but no one has reported success.

The luminet bootloader does work but it is highly specialized.

If you plan to use the internal oscillator, use serial for the transport, and disable RESET you could easily brick a processor.  The internal oscillator is ±10%.  A good rule of thumb is ±4.5% for serial communications.  Assuming the un-tuned oscillator frequency is evenly distributed there is about a 50% chance of bricking.

Tom Carpenter

#5
Jul 31, 2012, 12:31 am Last Edit: Jul 31, 2012, 12:38 am by Tom Carpenter Reason: 1
Duly noted.
I may end up running the serial communications at as low a BAUD rate as possible to try and reduce the risk of an issue.
I will also experiment with the bootloader without disabling the reset to begin with, and then if I can get it working reliably, i will set the disable reset bit in the fuse.
~Tom~

Tom Carpenter

#6
Jul 31, 2012, 01:00 am Last Edit: Jul 31, 2012, 01:06 am by Tom Carpenter Reason: 1
Here is one for you, in the make file, there is a value for where the optiboot version number is stored in the program memory. It would appear that this number positions the optiboot version such that it overlaps part of the bootloader code. I have corrected it in my make file to move it to tuck in just after the end of the bootloader, but is it possible that this may be why there are so many issues with the attiny84 chip?
Code: [Select]

luminet: TARGET = luminet
luminet: MCU_TARGET = attiny84
luminet: CFLAGS += '-DLED_START_FLASHES=3' '-DSOFT_UART' '-DBAUD_RATE=9600'
luminet: CFLAGS += '-DVIRTUAL_BOOT_PARTITION'
luminet: AVR_FREQ = 1000000L
luminet: LDSECTIONS = -Wl,--section-start=.text=0x1d00 -Wl,--section-start=.version=0x1efe
luminet: $(PROGRAM)_luminet.hex
luminet: $(PROGRAM)_luminet.lst

This bit:
--section-start=.version=0x1efe
should be:
--section-start=.version=0x1f5c
To prevent it overwriting and corrupting part of the bootloader




The other thing is that I would like to move the bootloader to start at 0x1DA0 rather than 0x1D00 as otherwise there is two pages of wasted space after the bootloader (128bytes).
I have figured out how to move the codes starting position using the makefile, but I get the impression it is not that simple. In the optiboot.c file there are the following two bits of code:
Code: [Select]
#ifdef VIRTUAL_BOOT_PARTITION
     if ((uint16_t)(void*)address == 0) {
       // This is the reset vector page. We need to live-patch the code so the
       // bootloader runs.
       //
       // Move RESET vector to WDT vector
       uint16_t vect = buff[0] | (buff[1]<<8);
       rstVect = vect;
       wdtVect = buff[8] | (buff[9]<<8);
       vect -= 4; // Instruction is a relative jump (rjmp), so recalculate.
       buff[8] = vect & 0xff;
       buff[9] = vect >> 8;

       // Add jump to bootloader at RESET vector
       buff[0] = 0x7f;
       buff[1] = 0xce; // rjmp 0x1d00 instruction
     }
#endif


Code: [Select]
#ifdef VIRTUAL_BOOT_PARTITION
     do {
       // Undo vector patch in bottom page so verify passes
       if (address == 0)       ch=rstVect & 0xff;
       else if (address == 1)  ch=rstVect >> 8;
       else if (address == 8)  ch=wdtVect & 0xff;
       else if (address == 9) ch=wdtVect >> 8;
       else ch = pgm_read_byte_near(address);
       address++;
       putch(ch);
     } while (--length);
#else


Could someon explain to me how they work so I can go about making the correction to account for the change in the start of the bootloader.
~Tom~

Tom Carpenter

Ahh, I figured out how to make the change.

Compiling:
Code: [Select]
int main(void){
  __asm__ __volatile__ (
    "   rjmp  0x1D00\n"
  );
}

Nicely explained it!
~Tom~

Elijahg

What's the reason for needing a boot loader? It uses a fairly large amount of space on a chip with so little flash space!

Tom Carpenter

#9
Jul 31, 2012, 03:03 am Last Edit: Jul 31, 2012, 03:06 am by Tom Carpenter Reason: 1
I explained at the beginning. In the end, I will be disabling the Reset pin so that it can be used as an additional IO pin. However if you do this, you can no longer program it using ISP. Instead you have to use a high voltage programmer, which would blow up other things on the board (its a surface mount chip). The bootloader adds an additional way in which it can be programmed without the need for a high voltage programmer, or the reset pin (a power cycle should work to reset it for bootloading).

Optiboot isn't that bad in terms of size. The version I compiled leaves 7552 bytes (7.375kB) of flash for the sketch. I also moved where in the flash the bootloader was slightly which recovered an extra 128 bytes. That is still lots more space than there is on an attiny44.
~Tom~

Elijahg

Apologies, I somehow missed that part of your post...! I'm impressed with how small you got the bootloader though.

Perhaps you could (at the expense of board size) use resistors and zeners to clamp the off-chip voltage to 5v, which due to the resistors, would allow a HV programmer to program the chip at HV still? Or if you only need to change the program very occasionally, perhaps you could simply use solder bridges? Of course either way you'd need a HV programmer, but just an idea anyway :)

Tom Carpenter

I have succeeded!

With a bit of modification of Optiboot, a bit of optimisation, and a half rewrite of optiboots software UART, I now have an attiny84 with a so far reliable bootloader which only takes up 576byte of the 8k.

It is running at 9600 baud, so uploading is slow, but it works.

After a bit more testing, I will post the bootloader and source, along with a new Tiny core that I have been working on. It is largely based around the existing one, but rewritten so that Print matches Arduino 1.0, everything is configured through pins_arduino.h files (one for each type), and it should be much easier to add new processors - just a new pins_arduino.h file (i'll make a thread for it once tested).
~Tom~

Tom Carpenter

After a slight misshap and a bricked chip, I got the bootloader working with the reset pin disabled (just a power cycle is needed to enter bootloader mode).

What I hadn't realised the first time is that ArduinoISP burns the fuse FIRST, then the program space. Which means that it essentially disabled Serial Programming just before it burned the bootloader. Fortunately this site: http://www.rickety.us/2010/03/arduino-avr-high-voltage-serial-programmer/ helped me recover the original fuse settings. I then burned the bootloader without reset disabled, and then used the HV programmer from the link to burn the new fuse settings, disabling the reset pin. And it works :D

What I will do next time to avoid having to use the HVP is to burn the bootloader without the RSTDSBL bit set, then burn it again with it set. The second time won't change the program memory, but it will set the fuse.
~Tom~

martin_bg

#13
Aug 26, 2012, 03:37 pm Last Edit: Aug 26, 2012, 04:14 pm by martin_bg Reason: 1
Tom, this is great news. I have quite a few projects on Attiny84 and have been looking for a bootloading solution for quite some time now..

Do you plan to document this and release your modifications? edit: got too excited and didn't read carefully :)

Tom Carpenter

I will be on holiday for the next couple of weeks, but after that I will post it :)
~Tom~

Go Up