I found an appnote from AVR freaks that looks interesting. It says the
bootloader works in combination with AVRprog (AVRstudio), but since all
code is supplied, it shouldn't be hard to figure out the available
functionality (and build your own update.exe ?).
http://www.avrfreaks.net/Tools/showtools.php?ToolID=328
Regards
Reply by Lewin A.R.W. Edwards●January 8, 20052005-01-08
> As cheap as CPUs are, you might consider a second CPU whose job is to
> reprogram the first one.
Sure, but this is slightly more effort than writing a custom bootloader in
the main CPU :)
--
Here, in a large house, formerly a house of state, lives Mr. Tulkinghorn. It
is let off in sets of chambers now, and in those shrunken fragments of its
greatness, lawyers lie like maggots in nuts.
Reply by ●January 7, 20052005-01-07
>Sounds dangerous to me. It means unsophisticated personnel have
>the ability to (possibly accidentally) update the firmware with
>unknown data. Experience shows that even 8 levels of "Are you
There is a potential for erasure, yes. However the downside risk is not
enormous. This is a vending application. The field tech needs a way to
get auditing information (credits in, product dispensed), modify a few
parameters like pricing and some specialized information related to the
product being dispensed, and also run some simple tests to verify that
the sensors and actuators are working OK.
The original plan was to use a laptop running a VB app to do the UI
and, if firmware upgrades are necessary (I think this will be rare;
everything we could think of is already parameterized in EEPROM), let
the field tech use an ISP cable and a batchfile-based reflash
operation. However the end-user wants something pocket-sized rather
than a big ol' laptop, hence my request for a bootloader.
The BOM cost for the whole board is in the order of $50, and all the
I/Os are on a few D connectors, so it is not much effort for the tech
to carry around one or two spare boards, too. The board is designed so
that if the chip does happen to get erased or worse than erased (e.g.
bad clocking option selected), it can be HV-programmed in circuit.
Reply by CBFalconer●January 7, 20052005-01-07
larwe@larwe.com wrote:
>
... snip ...
>
> Not what I'm looking for - The application gathers some data, which is
> in EEPROM, The end-user wants to collect, analyze and modify this data
> with their PDA. I.e. they need a UI that says "Current setting A is 54,
> press < to decrement, > to increment. Since you last visited, sensor B
> has triggered 47 times". They want the firmware update feature to be
> built into this UI. The person doing that UI doesn't want to have to
> learn too much about flash-loader protocols.
Sounds dangerous to me. It means unsophisticated personnel have
the ability to (possibly accidentally) update the firmware with
unknown data. Experience shows that even 8 levels of "Are you
sure" queries will still fail to protect, even with knowledgeable
operators.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●January 7, 20052005-01-07
>This is the device you are looking for, we use these to upgrade AVR
firmware
>in the field by non-electronic people.
Not what I'm looking for - The application gathers some data, which is
in EEPROM, The end-user wants to collect, analyze and modify this data
with their PDA. I.e. they need a UI that says "Current setting A is 54,
press < to decrement, > to increment. Since you last visited, sensor B
has triggered 47 times". They want the firmware update feature to be
built into this UI. The person doing that UI doesn't want to have to
learn too much about flash-loader protocols.
Reply by John Dyer●January 7, 20052005-01-07
<larwe@larwe.com> wrote in message
news:1104984223.049715.178410@c13g2000cwb.googlegroups.com...
> I'm building an AVR-based machine controller for a customer, and he has
> asked if I can make the unit upgradable from a PDA. The end-user wants
> to read/write EEPROM setup data from a handheld device (they're
> currently choosing between Palm or WinCE) and for this purpose I added
> a serial port and simple comms protocol in the original design. Now he
> wants to be able to upgrade the firmware over that interface too, so
> the field reps don't have to lug out a laptop and ISP cable.
>
> The catch is that he wants to implement the minimum possible custom
> software on the PDA side, and the bootloaders I've found seem to
> require variously complex back-end support on the PC; they either
> emulate an STK500, or they use proprietary Windows back-ends. I guess
> that recompiling uisp for WinCE is not out of the question, but it
> seems like a slippery slope towards software horror.
>
> Is there an AVR bootloader out there (for mega32 running off internal
> RC at 8MHz) that can accept a simple HEX file sent dumbly over RS232 at
> a known, fixed baud rate, with no feedback or flow control?
> Reasonably-priced buyware is not out of the question, but commissioning
> a custom bootloader is not an option - if it was, then I'd be writing
> it myself. This is a low volume application; the total production
> volume is unlikely to exceed 1000 units over two years.
>
Reply by Mikael Ejberg Pedersen●January 6, 20052005-01-06
On 6 Jan 2005 12:38:12 -0800, larwe@larwe.com wrote:
>I'll search avrfreaks when I get home tonight. Sounds like it's a
>pretty close match to my needs, thanks!
Well, I tried to find it, but the search engine won't go back further
than early 2004. I guess it has something to do with the big change of
forum software they did back then.
Instead, just grab it here:
http://www.ejberg.dk/temp/boot16.zip
It is written for the Mega16 at 16 MHz (and 9600 baud). For some other
crystal frequency or baudrate, you need to adjust some constants.
Also for other size processors, you probably need to rewrite the flash
write part of the code.
Best regards,
Mikael
--
Mikael Ejberg Pedersen
Reply by ●January 6, 20052005-01-06
Hi Mikael,
>I've made a bootloader once, but perhaps it is too simple. It does not
>take a HEX file, but rather a straight binary image. And it is sent
I'll search avrfreaks when I get home tonight. Sounds like it's a
pretty close match to my needs, thanks!
Reply by Mikael Ejberg Pedersen●January 6, 20052005-01-06
On 6 Jan 2005 06:38:58 -0800, larwe@larwe.com wrote:
>Ideally I want the customer to be able to use a simple dumb
>terminal program to send the firmware upgrade as a text HEX dump.
I've made a bootloader once, but perhaps it is too simple. It does not
take a HEX file, but rather a straight binary image. And it is sent
with the X-modem protocol, so almost every standard terminal program
can send it.
I think I published it a long time ago over at avrfreaks.net. If it
sounds interesting, I can try to dig it up from somewhere.
Best regards,
Mikael
--
Mikael Ejberg Pedersen
I read about AVRBL while I was googling, but the way I understood it,
there is still a proprietary protocol involved (hence the proprietary
Windows app shipped with the product). I'll take a closer look.