Bootloader Recommendation

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All,

I would like to try to add a bootloader to my Mega324. Can someone please recommend a simple bootloader that works with AVRDUDE and has good documentation? I think it will help learn more about bootloaders by looking at an existing implementation.

My end goal is to be able to program my MCU wirelessly via bluetooth.

Any help is appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

this one has PC side GUI software + AVR side code for many AVRs.
https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I will take a look at that one.

Edit: I know you posted this before, but I wasn't sure if it would work with AVRDUDE, but now I see that AVRDUDE can handle AVR109, so I think it should work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the AVR code with BLIPS require that the reset vector point to the bootloader code? If the reset vector does point to the bootloader code, then does that mean I can't call the bootloader from within the application code? It seems like my datasheet is implying this.

ATMEGA324 Datasheet:

Quote:
Entering the Boot Loader takes place by a jump or call from the application program. This may
be initiated by a trigger such as a command received via USART, or SPI interface. Alternatively,
the Boot Reset Fuse can be programmed so that the Reset Vector is pointing to the Boot Flash
start address after a reset. In this case, the Boot Loader is started after a reset. After the application
code is loaded, the program can start executing the application code. Note that the fuses
cannot be changed by the MCU itself. This means that once the Boot Reset Fuse is programmed,
the Reset Vector will always point to the Boot Loader Reset and the fuse can only be
changed through the serial or parallel programming interface.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
then does that mean I can't call the bootloader from within the application code?

Err no. Most bootloaders are done such that BOOTRST is programmed so that they always take first control (there can be occasions when there is NO app code so it has to be this way). They would usually (a) check to see if communications is being attempted and (b) if a valid app exists. If no to (a) and yes to (b) then it does a "JMP 0". But nothing precludes the app that's been entered later calling back to the bootloader.

Consider if BOOTRST was not used and a corrupt app were ever delivered - you'd never be able to get back into the bootloader if the setup RELIED on an app->boot jump.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Clawson, that makes a lot of sense.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This thread came quite handy today. I just wanted
to add a bootloader to my MEGA88 board.
(Never used a bootloader on AVRs before)

This thread answered my questions and within 1 hour
I got BLIPS and bootloader up and running.

Special thanks to stevech
:D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a peice of code in BLIPS that seems wrong to me.

boot_esc_lp:	;;rcall	nada		; kill some time
		dec		R23
		brne	boot_r_1
		dec		R24
		brne	boot_r_1		; 16 bit counter loop

;.ifdef	LED_DDR
;		OUTREG		LED_PORT,R25			; this makes LED blink visibly
;.endif	
		dec		R25
		brne	boot_r_1

; --- TIMED OUT, STARTUP USER PROGRAM
boot_r_0:
		clr		R30				; ensure 0 if jump here from elsewhere
		clr		R31
		OUTREG	UARTC,R30			; disable UART

.ifdef	LED_DDR
		clr		R24
		OUTREG	LED_DDR,R24			; v3.1
		OUTREG	LED_PORT,R24			; LED port and bit, LED will go dark now
.endif
		ijmp					; timeout, jump to address zero

boot_r_1:
		INREG	R16,USTAT
		sbrs 	R16,URXC 			; Skip if UART byte has arrived
		rjmp 	boot_esc_lp			; not yet, loop

		INREG	R16,UDATA 			; get received data in R16
		cpi		R16,0x1b			; ESC?
		breq	boot_esc_lp			; 
		rjmp	L10					; decode 1st received char that's not an ESCAPE

According to the notes BLIPS should wait for an escape character to start the bootload, however when I read the code I seems to me that it waits for any character except the escape char.

In the last three line this what I read:
1)The value of 0x1b is subracted from the UART data. If the UART data is the same as 0x1b the Z flag will be set
2)If the Z flag is set go back to the loop
3)If not jump to L10 where the bootloader starts.

As I am not very good with assembly, can someone please tell me if I my interpretation is correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The author will be here shortly to explain it :)

While looking at that piece of code, I did notice one thing. If you get a watchdog timeout in your app (and assuming the boot reset fuse is on), you will be waiting around in that loop for 1.5 seconds. If you have a newer avr (like your 324), WDRF overrides WDE, so you will continually timeout the watchdog in that loop leading to forever watchdog resets (default watchdog timeout is 16ms). At least that's what it looks like to me. Adding a wdr in there would take care of it.

If you (or anyone) wants a non-gui ascii only bootloader, I still have mine posted-
http://www.mtcnet.net/~henryvm/A...
I run it on a mega164p, mega88, mega168, along with TeraTerm terminal (better than Hyperterminal).

I'm working on making a no-compile required hex file creator for the bootloader. Choose avr (any with a boot section), choose baud, choose character trigger or pin trigger, out comes a hex file for your avr.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
If you (or anyone) wants a non-gui ascii only bootloader, I still have mine posted-
http://www.mtcnet.net/~henryvm/A...
Thanks for the offer but I want an AVR109 bootloader so hopefully I can use AVRDUDE.

Interesting point, I will remember that if I ever want to use the watchdog timer.

One thing you may want to consider with your bootloader is UART doublespeed support. Both of the two bootloaders I have looked at I had to modify the source code to get 115200 baud because I needed the UART in doublespeed mode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: I got Steve's bootloader to work with the BLIPS gui. Thanks Steve. I still don't understand that section in the source code though. Next I will try to get it to work with AVRDUDE.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
One thing you may want to consider with your bootloader is UART doublespeed support. Both of the two bootloaders I have looked at I had to modify the source code to get 115200 baud because I needed the UART in doublespeed mode.
High speeds without the magic crystals do not interest me. There's always a .2percenter around somewhere without U2X. In any case, since there is no flow control, a line delay of ~17ms is required. And since hex records are limited to 16 data bytes, it does not make much difference in speed from 38.4kb to 115.2kb. I use 38.4kb for 8mhz crystals, and 115.2kb when a magic crystal is used. The big gain that can be made is getting a hex record into a larger size. A full 164p will take 33sec at 115.2 with a normal 16 byte data record, and 8sec with a 128byte record. The actual time spent in transmitting characters is the same for both (about 4sec). Calculating for 38.4kb, the time spent transmitting would be about 12sec. So from 115.2kb to 38.4kb costs 8 seconds for a full 164p.

You may want to calculate what the actual time difference will be for whatever you use. If you have to give up a few seconds for reliable communications, it would be worth it in my opinion.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To see whether the BLIPS bootloader waits for ESC or
not I connected a terminal program.

Operation here is as follows: The first
non-ESC character switches to BOOTLOAD and is
already correctly interpreted as command.
So it skips the precceding ESC characters.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dpaulsen wrote:
Update: I got Steve's bootloader to work with the BLIPS gui. Thanks Steve. I still don't understand that section in the source code though. Next I will try to get it to work with AVRDUDE.

OK. Isn't AVRDUDE a PC-side downloader? As is the BLIPS PC-side? BLIPS PC-side also has a command line batch mode - described in the docs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
dpaulsen wrote:
Update: I got Steve's bootloader to work with the BLIPS gui. Thanks Steve. I still don't understand that section in the source code though. Next I will try to get it to work with AVRDUDE.

OK. Isn't AVRDUDE a PC-side downloader? As is the BLIPS PC-side? BLIPS PC-side also has a command line batch mode - described in the docs.

I was trying to get AVRDUDE to work with your bootloader not BLIPS. Sorry for the confusion.

I actually did get AVRDUDE to work with one minor glich after I slowed down the baud rate to 38.4 kbps. The only glich is that the bootloader doesn't provide the carriage return response when AVRDUDE sends the exit command.

After getting AVRDUDE to work I tried to use bluetooth instead of a serial cable, and that didn't work at all. For some reason when the bluetooth gets bombarded with data, it is unable to keep the connection. I suspect that the USB bluetooth dongle COM port emulator is the problem.

I think I am going to give up on wirelessly programming a target. At least I learned quite a bit by attempting it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I think I am going to give up on wirelessly programming a target. At least I learned quite a bit by attempting it.

I've used BLIPS to run AVR bootloading across WiFi and wired ethernet. Using Moxa and also Lantronix serial-to-ethernet converters and their Windows Virtual COM port. Works fine with the COM port simulator. I also did TCP and UDP from BLIPS to the Moxa/Lantronix devices, by-passing the virtual COM port driver.

Using the COM port driver is easy; makes the IP LAN/WiFi transparent.

I've also done bootloading across 802.15.4 wireless, for ARMs, not AVRs.