Best bootloader over FDTI USB (mega324)

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

I have an existing and a new application both using mega324, they have plenty of room (when I went from mega16 to 324 the 324 was cheaper than a 164)(and the other is just a LCD driver chip).

One have a real RS232 (max232 no handshake), and the other use USB using a FT232 (a real one :) ).

 

I use windows and a USB to rs232 on my PC (And don't want to change the default driver setting!)

 

For both projects I have used this compiler "WinAVR-20100110\bin\avr-gcc.exe".

 

I would prefer to use the intel hex file direct (but it isn't a must)

 

I will prefer to use the  same bootloader , any sugestions? 

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

Well known ones include:

 

danni: fboot

stevech: BLIPS

westfw (maintainer): Optiboot

"fleury": stk500v2

 

Do you, for example, require to be able to deliver EEPROM?

 

Oh and asking for iHex will really reduce the options. Most use a 109 based protocol (or similar) which send addressing and the data as separate command packets but the input image is effectively binary though a tool such as avrdude can read iHex and then transmit in AVR109 protocol.

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

clawson wrote:
westfw (maintainer): Optiboot
Though not for mega324 the following is another use of Optiboot :

GitHub

Mighty 1284P Platform for Arduino

https://github.com/JChristensen/mighty-1284p

Mighty 1284P: An Arduino core for the ATmega1284P

...

Revision history

13May2014 Jack Christensen

  • Added a 1M baud version of Optiboot.

https://github.com/JChristensen/mighty-1284p/tree/v1.0.5/bootloaders 

 Arduino on ATmega1284P

...

  • FTDI. I use a Sparkfun FTDI breakout to program everything, so I’ve set this breadboard up with a connector for that mechanism.

"Dare to be naïve." - Buckminster Fuller

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

Thanks for the input.

I found out that chip45 has the hex files for the bootloader, for most avr's. and a PC program that can do app download. (so just program the bootloader, and set the bootloader flag, and then the PC program can download the normal app. hex file)

I guess only downside is that it's relative big but I don't care about that.

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

sparrow2 wrote:
chip45
Bear in mind that the chip45 bootloader has a serious flaw:

https://www.avrfreaks.net/comment/1198906#comment-1198906

 

A look at the latest version 2.9Q shows that it suffers from the same bug:

chip45boot2_atmega1284p_uart0_v2.9Q.hex:     file format ihex


Disassembly of section .sec1:

0001f800 <.sec1>:
   1f800:	21 e0       	ldi	r18, 0x01	; 1
   1f802:	a0 e0       	ldi	r26, 0x00	; 0
   1f804:	b1 e0       	ldi	r27, 0x01	; 1
   1f806:	01 c0       	rjmp	.+2      	;  0x1f80a
   1f808:	1d 92       	st	X+, r1
   1f80a:	a8 35       	cpi	r26, 0x58	; 88
   1f80c:	b2 07       	cpc	r27, r18
   1f80e:	e1 f7       	brne	.-8      	;  0x1f808
   1f810:	cf ef       	ldi	r28, 0xFF	; 255
   1f812:	d0 e4       	ldi	r29, 0x40	; 64
   1f814:	de bf       	out	0x3e, r29	; 62
   1f816:	cd bf       	out	0x3d, r28	; 61
   1f818:	11 24       	eor	r1, r1

... i.e. r1 is still used uninitialised.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Nov 15, 2014 - 03:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok thanks for the input.

Is this only an error in 1284 ? (more than 64K I use 324)

What does the error mean, I can't use it if the normal app. sometimes don't boot!

But if a field update need more than 1 reset (reboot) it's not a big deal.

I have used it about 10 times now and it seems to work every time !?

Last Edited: Sat. Nov 15, 2014 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
Is this only an error in 1284 ? (more than 64K I use 324)
I expect it is there for every target, although I haven't checked.  It is there in the 1284p (all versions) and the 324p (all versions).

 

Quote:
What does the error mean, I can't use it if the normal app. sometimes don't boot!
It's the bootloader that sometimes goes haywire.  Since the error is an uninitialised r1 which is then used to initialise .bss, there's no telling what will happen.  There are (at least) 255 failure modes, since r1 can take on 255 non-zero states, with which all of .bss will be initialised.  Since the bootloader is also responsible for launching the the app, your guess is as good as mine as to what will happen.  I suppose you could narrow down the failure modes and behaviours a bit by looking at the source code (for $), or doing a full disassembly and analysis of the .hex.

 

Quote:
But if a field update need more than 1 reset (reboot) it's not a big deal.

I have used it about 10 times now and it seems to work every time !?

This really depends upon your app's hardware and usage profile.

 

The 'bug' is that r1 is used to clear .bss before r1 is itself cleared.  A legitimate question is 'does this matter?'.  Perhaps in most cases it doesn't.  The GP register file in an AVR are, like SRAM, uninitialised after a reset.  However, if an AVR is powered up from a completely unpowered state (Vcc = 0 V), all of the GP registers will hold 0x00 out of reset (at least the two device types I've tested: t85 and m328).  Note that this is different than the cold-power-up state of SRAM, which is 'random-ish'.

 

All 0x00.  So no problem there, at least if you power down completely and the PS caps actually fully discharge.

 

One of the failure paths for this chip45 bug is what happens to the GP register file when Vcc is allowed to drop below about 0.3V, but not completely reach 0V.  Under these conditions, the register contents become corrupted.  Were a device with a chip45 bootloader to be power-cycled too quickly (leaving insufficient time for Vcc to drop to 0V), then r1 might not be 0x00 after the power-on reset.  Chip45 will barf.

 

Similarly if an ASM user app uses r1 differently than does GCC (i.e. to hold non-zero values), then a powered reset would make chip45 barf.  Even GCC uses r1 to hold the results of a MUL.  An unfortunately timed reset (after a MUL but before the EOR R1,R1) would make chip45 barf.

 

The fix is simple.  Tell chip45 to fix their code.  Or, just fix it yourself.  Without the source code you could still patch the binary.  You need only move the EOR R1,R1 to the first instruction.  The intervening instructions are completely relocatable.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Nov 16, 2014 - 07:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok thabks I think I will do both.

But I'm not sure that it's just to put the "clr" r0 up front. The way it's build up it looks like are a label to :

st	X+, r1

And that will move!

so the safe fix would be to start with a rjmp to the end,  where it clr r0 and load r18 and then continue at 2. instruction.

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

sparrow2 wrote:

st	X+, r1

And that will move!

That doesn't matter.  X won't change as a result of moving the instruction.

 

There is a label, yes, but only used by the brne at the end of (what is surely) the <__do_clear_bss> code fragment.  From chip45boot2_atmega324p_uart0_v2.9Q.hex:

chip45boot2_atmega324p_uart0_v2.9Q.hex:     file format ihex


Disassembly of section .sec1:

00007800 <.sec1>:
    7800:	21 e0       	ldi	r18, 0x01	; 1
    7802:	a0 e0       	ldi	r26, 0x00	; 0
    7804:	b1 e0       	ldi	r27, 0x01	; 1
    7806:	01 c0       	rjmp	.+2      	;  0x780a
    7808:	1d 92       	st	X+, r1
    780a:	a8 35       	cpi	r26, 0x58	; 88
    780c:	b2 07       	cpc	r27, r18
    780e:	e1 f7       	brne	.-8      	;  0x7808

Note that the target for the brne is 0x7808.  That address is not the target of any other jumps, calls, or branches.  That's because it is taken (or adapted by the chip45 folks) from lib1funcs.S:

/* __do_clear_bss is only necessary if there is anything in .bss section.  */

#ifdef L_clear_bss
	.section .init4,"ax",@progbits
DEFUN __do_clear_bss
	ldi	r18, hi8(__bss_end)
	ldi	r26, lo8(__bss_start)
	ldi	r27, hi8(__bss_start)
	rjmp	.do_clear_bss_start
.do_clear_bss_loop:
	st	X+, __zero_reg__
.do_clear_bss_start:
	cpi	r26, lo8(__bss_end)
	cpc	r27, r18
	brne	.do_clear_bss_loop
ENDF __do_clear_bss
#endif /* L_clear_bss */

All that is required is to clear r1 (not r0, BTW) before .do_clear_bss, or at least before the rjmp to .do_clear_bss_start.  Since the intervening code is all relocatable and self-contained, there's no need to recompute or worry about adjusting branch operands.

 

We go from this:

00007800 <.sec1>:
    7800:	21 e0       	ldi	r18, 0x01	; 1
    7802:	a0 e0       	ldi	r26, 0x00	; 0
    7804:	b1 e0       	ldi	r27, 0x01	; 1
    7806:	01 c0       	rjmp	.+2      	;  0x780a
    7808:	1d 92       	st	X+, r1
    780a:	a8 35       	cpi	r26, 0x58	; 88
    780c:	b2 07       	cpc	r27, r18
    780e:	e1 f7       	brne	.-8      	;  0x7808
    7810:	cf ef       	ldi	r28, 0xFF	; 255
    7812:	d8 e0       	ldi	r29, 0x08	; 8
    7814:	de bf       	out	0x3e, r29	; 62
    7816:	cd bf       	out	0x3d, r28	; 61
    7818:	11 24       	eor	r1, r1
    781a:	1f be       	out	0x3f, r1	; 63
    781c:	6b c0       	rjmp	.+214    	;  0x78f4

... to this:

00007800 <.sec1>:
    7800:	11 24       	eor	r1, r1
    7802:	1f be       	out	0x3f, r1	; 63
    7804:	21 e0       	ldi	r18, 0x01	; 1
    7806:	a0 e0       	ldi	r26, 0x00	; 0
    7808:	b1 e0       	ldi	r27, 0x01	; 1
    780a:	01 c0       	rjmp	.+2      	;  0x780e
    780c:	1d 92       	st	X+, r1
    780e:	a8 35       	cpi	r26, 0x58	; 88
    7810:	b2 07       	cpc	r27, r18
    7812:	e1 f7       	brne	.-8      	;  0x780c
    7814:	cf ef       	ldi	r28, 0xFF	; 255
    7816:	d8 e0       	ldi	r29, 0x08	; 8
    7818:	de bf       	out	0x3e, r29	; 62
    781a:	cd bf       	out	0x3d, r28	; 61
    781c:	6b c0       	rjmp	.+214    	;  0x78f4

Note how I also moved the initialisation of SREG to disable interrupts earlier.

 

For my money, I would do this instead:

00007800 <.sec1>:
    7800:	f8 94       	cli
    7802:	11 24       	eor	r1, r1
    7804:	21 e0       	ldi	r18, 0x01	; 1
    7806:	a0 e0       	ldi	r26, 0x00	; 0
    7808:	b1 e0       	ldi	r27, 0x01	; 1
    780a:	01 c0       	rjmp	.+2      	;  0x780e
    780c:	1d 92       	st	X+, r1
    780e:	a8 35       	cpi	r26, 0x58	; 88
    7810:	b2 07       	cpc	r27, r18
    7812:	e1 f7       	brne	.-8      	;  0x780c
    7814:	cf ef       	ldi	r28, 0xFF	; 255
    7816:	d8 e0       	ldi	r29, 0x08	; 8
    7818:	de bf       	out	0x3e, r29	; 62
    781a:	cd bf       	out	0x3d, r28	; 61
    781c:	6b c0       	rjmp	.+214    	;  0x78f4

... to guarantee interrupts are disabled even if the bootloader is reached via user app code.  But this can be handled with the proper BLB modes (mode 3 or 4 for both BLB0 and BLB1).

 

The proper fix of course is for the chip45 folks to fix their source, by moving the code which clears r1 ahead of the code for clearing bss.  The code for clearing r1 is part of <__init>, which is found in gcrt1.S:

	.section .init2,"ax",@progbits
	clr	__zero_reg__
	out	AVR_STATUS_ADDR, __zero_reg__
	ldi	r28,lo8(__stack)
#ifdef __AVR_XMEGA__
	out	AVR_STACK_POINTER_LO_ADDR, r28
#ifdef _HAVE_AVR_STACK_POINTER_HI
	ldi	r29,hi8(__stack)
	out	AVR_STACK_POINTER_HI_ADDR, r29
#endif	/* _HAVE_AVR_STACK_POINTER_HI */
#else
#ifdef _HAVE_AVR_STACK_POINTER_HI
	ldi	r29,hi8(__stack)
	out	AVR_STACK_POINTER_HI_ADDR, r29
#endif	/* _HAVE_AVR_STACK_POINTER_HI */
	out	AVR_STACK_POINTER_LO_ADDR, r28
#endif  /* __AVR_XMEGA__ */

#ifdef __AVR_3_BYTE_PC__
	ldi	r16, hh8(pm(__vectors))
	out	_SFR_IO_ADDR(EIND), r16
#endif	/* __AVR_3_BYTE_PC__ */

#ifdef __AVR_HAVE_RAMPD__
	out	AVR_RAMPD_ADDR, __zero_reg__
	out	AVR_RAMPX_ADDR, __zero_reg__
	out	AVR_RAMPY_ADDR, __zero_reg__
	out	AVR_RAMPZ_ADDR, __zero_reg__
#endif

In fact all of this can come before <__do_clear_bss>.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Nov 16, 2014 - 04:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am always wary of proprietary code.     I suppose that I am too mean to buy a chip45 licence.

 

If the code is proprietary,   and the chip45 company goes broke,   you are stuck with broken software.     And their copyright probably means that Joey is not allowed to publish a fix.

 

As far as I can see,    chip45 requires a custom PC program to talk to the bootloader.     Again,   you have a problem with a company that goes broke.

 

I would stick with Optiboot that uses a published stk500v1 protocol.     Avrdude always works.   Many IDEs support it now.

Yes,   there are Optiboot 'equivalents' that handle EEPROM correctly.     And even report fuses, lockbits, signatures correctly (from within a 512byte BOOTSECTION).   

 

David.

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

david.prentice wrote:
And their copyright probably means that Joey is not allowed to publish a fix.
Perhaps, but:

HEX FILE LICENSE
chip45 GmbH & Co. KG grants the permission to use the precompiled chip45boot2 hexfiles for either non-
commercial or commercial applications without limitations and free of charge. The precompiled chip45boot2
hexfiles come “as is” without any warranties.

SOURCE CODE LICENSE
If you want to use and modify the bootloader source code, e.g. to add customer specific functions, the source code
can be purchased at http://go.chip45.com/chip45boot2. The source code is being distributed as a single ZIP file,
which provides an AVR-Studio project file, the WinAVR source files and a batch file for automatic generation of the
MCU specific hex files. The source code is well commented and can be easily modified and extended according to
your special requirements.
• You may use and modify the bootloader source code for any of your products or projects.
• You may distribute unlimitted compiled binary versions of the bootloader.
• You may not distribute your modified source code to a third party.
• You may not redistribute the original source code to a third party.
• You may redistribute your license of the bootloader to a third party only with permission of chip45 GmbH &
Co. KG.
• The chip45boot2 source code comes “as is”, without any warranties.
The current release of chip45boot2 was compiled with AVR GNU Toolchain 3.4.1.95, comes with Atmel Studio 6
(6.0.1996 Service Pack 2.

Restrictions on the source code, yes.  But I don't have the source code.  I disassembled the freely available pre-compiled .hex files.  I don't see a restriction on their use which would preclude publishing what amounts to a binary patch.  However if a moderator disagrees, feel free to trim the code from my post above.

 

It irks me somewhat that the chip45 folks are happy to blame GCC when it seems clear the problem is the way they cherry-picked code from GCC and assembled/linked it in the wrong order:

V2.9P: changed app_start(); call for start of application, since latest avr-gcc (Studio 6.1) doesn't generate a proper jmp to address zero.

... and they misdiagnose the problem to boot! ... pun intended ;)

 

david.prentice wrote:
I would stick with Optiboot that uses a published stk500v1 protocol.
+1

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Nov 16, 2014 - 04:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If size is not too much of an issue, there are also the older Arduino bootloaders (atmegaboot, adaboot.)  These are more full featured, at the expense of being 4x the size of optiboot (2k vs 0.5k)  They're still in common use on many of the arduino-derivative boards, and pretty solid.

 

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

My problem is time.

Are there a optiboot that work on mega324 out of the box?

Or a simple cookbook to make it work?

At the moment I just had to show the costumer that we could update through the debug port :)

 

  

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

I guess Chip45 is OK but you will have to pay for access to the source code. If I was doing that I think I'd expect a product that was bug fixed and working or some level of "service" as that's surely what you are paying for? They don't seem to demonstrate that they are very proactive when it comes to code maintenance so personally I'd be very wary :-(

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

But I just downloaded the hex file, set boot flags, and installed there program, and I could download my app the first time.

If there "error" was big (happen often) I would expect them to make changes.

When I first started with AVR's  (org.) 8515 they didn't have registers set to 0 at boot. But my guess is that all (new) avr's run a small boot program to init things before

it jump to addr. 0x0000 (or boot addr.), and that it clear the registers.

 

I don't care about call from the app to the bootloader, actually I would like to prevent self update of the flash. 

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

I would expect them to make changes.

We all would - that was my point - that thread Joey linked to was from May this year. It's now November - how long does it take for a bug like this to be fixed??

 

I don't know about you but this would give me no confidence whatsoever in the product they are trying to sell you.

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

sparrow2 wrote:
When I first started with AVR's  (org.) 8515 they didn't have registers set to 0 at boot. But my guess is that all (new) avr's run a small boot program to init things before

it jump to addr. 0x0000 (or boot addr.), and that it clear the registers.

AFAIK there is no on-chip mechanism to initialise the GP register file.  It will survive a powered reset (WDRF, EXTRF) intact, just as does SRAM.  You can test this yourself.  The testing I've done shows it will survive BORF as well.  A PORF where 0 < Vcc <0.3 will result in corrupted GP registers (as well as SRAM).  Only PORF starting with 0 <= Vcc < some-very-small-voltage will result in the GP register file with all bits zero.  This is likely a consequence of the process, rather than some on-chip boot program.

 

Quote:
I don't care about call from the app to the bootloader, actually I would like to prevent self update of the flash.
That won't save you.  Since the GP registers including r1 can find themselves in a non-zero state after a non-zero-volt-POR reset, triggering an external reset to enter the bootloader can still suffer from this bug.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

In fact, early versions of optiboot had a bug where the init code did not set R1 to 0.  (R1 is the avr-gcc "known zero" register.)  It still worked "most" of the time, because the chip (application) was running other avr-gcc code that DID initialize R1.  But if your app did a lot of multiplication (one of the few things that does something else with R1), the bootloader for fail mysteriously.   This was fun to figure out!

 

PS: no, optiboot does not support the 324 "out of the box."  I haven't looked at the 324, so I don't know how difficult it would be to change.

 

Last Edited: Tue. Nov 18, 2014 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm... I wonder if this is an inherited bug from 'borrowed' Optiboot code...

 

chip45boot2_atmega324p_uart0_v2.53.hex:     file format ihex


Disassembly of section .sec1:

00007800 <.sec1>:
    7800:	11 e0       	ldi	r17, 0x01	; 1
    7802:	a0 e0       	ldi	r26, 0x00	; 0
    7804:	b1 e0       	ldi	r27, 0x01	; 1
    7806:	e2 e3       	ldi	r30, 0x32	; 50
    7808:	ff e7       	ldi	r31, 0x7F	; 127
    780a:	02 c0       	rjmp	.+4      	;  0x7810
    780c:	05 90       	lpm	r0, Z+
    780e:	0d 92       	st	X+, r0
    7810:	a0 30       	cpi	r26, 0x00	; 0
    7812:	b1 07       	cpc	r27, r17
    7814:	d9 f7       	brne	.-10     	;  0x780c

    7816:	11 e0       	ldi	r17, 0x01	; 1
    7818:	a0 e0       	ldi	r26, 0x00	; 0
    781a:	b1 e0       	ldi	r27, 0x01	; 1
    781c:	01 c0       	rjmp	.+2      	;  0x7820
    781e:	1d 92       	st	X+, r1
    7820:	a1 30       	cpi	r26, 0x01	; 1
    7822:	b1 07       	cpc	r27, r17
    7824:	e1 f7       	brne	.-8      	;  0x781e

    7826:	cf ef       	ldi	r28, 0xFF	; 255
    7828:	d8 e0       	ldi	r29, 0x08	; 8
    782a:	de bf       	out	0x3e, r29	; 62
    782c:	cd bf       	out	0x3d, r28	; 61
    782e:	11 24       	eor	r1, r1
    7830:	1f be       	out	0x3f, r1	; 63
    7832:	2c c0       	rjmp	.+88     	;  0x788c

 

Sure enough, r1 is used (.do_clear_bss?) before it is initialised.  Version 2.53 is the first officially released version.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]