Programming One AVR with Another

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

The problem of field upgrades has reared its head again; it's something I've never really solved to my satisfaction.

 

I want what amount to a disposable solution. If the end-user returns the 'upgrade unit' then that's great and we can re-use them. If not, then we're too out of pocket.

 

The target boards have easy access to a standard 6-pin ISP connector. So that's easy.

 

The idea I've had for an upgrade unit is a simple PCB containing the following...

 

*) an AVR

*) a decoupling capacitor

*) a 6-pin ISP header

*) a resistor

 

...that's it. Nothing else.

 

In an ideal world the upgrade unit AVR would have more flash than the target although, given that I never completely fill my flash, I could probably get away with the same size.

 

The 6-pin is wired as standard and is used to program the upgrade unit. It gets programmed with some code in the bootloader section. On power up this code reads the chip signature of the attached target and if correct it will transfer the code from its lower flash area to the target. This is accomplished via bit-banged SPI through the same 6-pin ISP connector.

 

Why bit banged? Because MISO and MOSI need swapping between the upgrade unit being programmed and it being the programmer. I don't want to mess around with links and jumpers. So it's bit banged SPI using the SPI pins but with MISO and MOSI swapped.

 

The resistor is there to isolate the reset pin.

 

Am I missing something as far as the technology goes?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Microchip PICkit3 and it's successor PICkit4 support the storage of a firmware image within the PICkit which then changes mode to become a self-contained programmer. All that is required is to connect to a 5/6 pin header and depress the "start" button. A 32K PIC24 device is programmed inside 5s.

 

Microchip are on a journey adding AVR to their PICkit4 programmers and ICD4 debugger but I get the impression they're dragging their heels a bit.

 

Then again Microchip aren't the only players in town, there may be a 3rd party self-contained/standalone AVR programmer available.

 

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

If you have an AVRisp I'd be tempted to take it apart and look at it.  I believe it's basically an AVR that programs AVRs, with an internal bootloader and a USB connection.

 

Seems to me that fifty cents worth of TTL glue logic could solve the bit-banging MISO/MOSI swap.  Use a stray AVR pin to trip output enables...  If you care.  S.

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

N.Winterbottom wrote:

...there may be a 3rd party self-contained/standalone AVR programmer available.

 

There are and I have a pile of them from Kanda. The problem is that they cost too much to send out and hope that they get sent back. I want to avoid the whole bit of having to invoice people when they don't return them or have to deal with the 'I'm sure Bob in dispatch posted it' scenario.

 

Scroungre wrote:

If you have an AVRisp I'd be tempted to take it apart and look at it.  I believe it's basically an AVR that programs AVRs, with an internal bootloader and a USB connection.

 

I've just downloaded the sketch for the UNO ISP, or whatever it's called.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Oh - Scratch the PICkit4 suggestion.

 

The MPLAB PICkit 4 now has Programmer-to-Go functionality for 8-bit, 16-bit, and 32-bit PIC, and SAM MCUs, dsPICs and MPUs. The firmware update comes with MPLAB X IDE v5.30. AVR available soon!

 Microchip attach a different meaning to the word "soon" than the rest of us.

 

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

Scroungre wrote:
Seems to me that fifty cents worth of TTL glue logic could solve the bit-banging MISO/MOSI swap.
Zero cents worth of software will do the same thing.  It's not just component cost, it's also board size and assembly time/cost.

 

Brian Fairchild wrote:

I want what amount to a disposable solution. If the end-user returns the 'upgrade unit' then that's great and we can re-use them. If not, then we're too out of pocket.

SD card (or microSD) and Cliff's bootloader?  Or at least, start there and add encryption.

 

For customers that can handle it, this is a zero-cost-to-you solution.  Customer provides SD card, you provide (possibly encrypted) firmware update as a download or attachment.  For customers who can't/won't figure out how to put a file onto an SD card themselves, then a few bucks and near-zero effort will get you a 4GB or 8GB card at almost any retailer.  I expect a bit of effort would locate far better deals online.

"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

Another suggestion, although it might be a bit late now - Skip the whole AVR programmer, and put the smarts into the 'field' device.  Have it, on powerup, go looking for an external SPI EEprom on its ISP header, and if it finds one containing a later program revision than it's already got, download and install it.

 

Then the 'upgrade' card is just a little postage stamp with an EEprom on it.  S.

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

joeymorin wrote:

Scroungre wrote:
Seems to me that fifty cents worth of TTL glue logic could solve the bit-banging MISO/MOSI swap.
Zero cents worth of software will do the same thing.  It's not just component cost, it's also board size and assembly time/cost.


 

Software ain't free either, but at least it's a one-time cost.  Note that I added, "If you care".  Speaking of board space, SD card holders are not small themselves...  His board already has an ISP header.  Whether it has an SD slot is not mentioned.

 

Also apropos of the OP:  If you're going to be trading off who's master and who's slave, you might get some argument over which AVR wants to drive the clock, SCL.  Probably easily made okay, but something to watch for.  S.

 

 

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

Scroungre wrote:
Software ain't free either, but at least it's a one-time cost
True, but whether developing peripheral-based SPI routines or bit-banged SPI routines, the differential cost is effectively zero.  Plenty of examples of both in the wild.

 

Scroungre wrote:
Speaking of board space, SD card holders are not small themselves
Also true, but that's a different question.  Glue logic on a programming dongle v.s. an alternative to a programming dongle.

"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

Scroungre wrote:

Have it, on powerup, go looking for an external SPI EEprom on its ISP header, and if it finds one containing a later program revision than it's already got, download and install it.

 

I've thought about that as well, certainly having a standard bootloader in everything I ship from now on feels like a good move. A quick BOFP (back of fag packet) calculation puts such a unit at the 2.50 price point.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

The EEprom idea, and the SD card idea, both have the interesting advantage that neither contains the whole program - if you're worried about someone swiping it.  Even if they do successfully extract the code, it's not the complete program, so if they program that into their own board, it's not going to work.

 

If you really wanted to get creative, you put on the 'upgrade card' just the parts of the code that changed, and the addresses of where to put them, and it becomes even more like a "software patch", where all you're sending is the changed bits.  Might make the bootloader a bit trickier, that.

 

Don't forget the cost of the anti-static bag to ship it in...  wink  S.

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

What about AlanK2's  really nice pocket programmers? I am using them exactly as you propose. Users in the U.S. are asked to return them; In fact, I  send them in bubble envelopes with a second pre-addressed and stamped bubble envelope inside. Foreign users for whom customs or mailing may be a problem are asked to return if it is convenient; they get a pre-addressed return envelope without a stamp since they need to be sent with local stamps.

 

You can contact Alan via PM on this forum.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

There is OptiLoader: https://github.com/WestfW/OptiLo...

And the Adafruit improvement of it: https://learn.adafruit.com/stand...

And also Nick Gammon's improvements: http://www.gammon.com.au/forum/?...

 

These were all aimed at installing/replacing/upgrading the bootloader on assorted Arduino boards, so they do things like store multiple bootloader images in flash and detect which one to program from the target device signature, but it would be a pretty easy modification to support burning an arbitrary larger image.  You just need to use a chip whose flash is a few K more than your target image.

 

Optiloader was based on the Arduino as ISP sketch (it just uses a different source of the bytes to program), so there's a nice warm-and-fuzzy open source history to all of these...

 

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

My very first attempt was something like you describe.  It was an atmega328 on some protoboard and then I made a pcb for it which I never built up.  I was trying to use a 328 to update a 328 and back then my image size was the full 32K because I was signing it at the end and not the middle.  This forced me to implement a compression algorithm on it and making up a firmware image was a complicated process that I did not love.  This was the very beginnings of the autoprogrammer that I sell that Jim mentioned.  I found it was much easier to throw an EEPROM on there and program it via USB than to have to program the programmer over ISP each time.  (I use inline 1x6 for ISP which is what these boards show instead of 2x3).

 

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

@alank2 Add a link in your  >> Account Settings >> Account Information >> Signature

 

https://www.avrfreaks.net/forum/...

 

So I don't have to look for it next time.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

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

A fine idea Ron - it is done!

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

Guess you kids aren't old enough to remember "Buttload" then? ;-)

 

(can you still get Butterflys though?)

 

EDIT: actually Dean put the code of Buttload into LUFA (ie AVRISP) so it's fairly easy to make a modern day "workalike" with USB connectivity by squeezing it into the smallest AVR-USB you can get - but, like the Butterfly had AT45 dataflash you would need some kind of storage in the design to carry the code image.

Last Edited: Tue. Apr 7, 2020 - 08:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This made me wonder about the possibilities. I found a project that has a GUI and the source code for the boot loader that is said to work on many avr/pic/TI ...etc. I only got it to work one time with a T84a device without a crystal over RS232, so beware.  I was also interested in using bitbang serial as I have blown out the USART RX,TX pins on my current mcu.  Ralph Doncaster has an implementation of the AVR305 half-duplex serial uart in assembler(I think it's in C too) that is easy to modify and understand. I did so with one of my projects to xfer data from a M328 to a Pic12f683. The bootloaders I was refering to are on Sourceforge and written in ASM - fairly easy to Frankenstein together with Ralph's shift out routine for spi without an HW usart.  Brian, I believe you are an asm or bilingual programmer and probably have your own routines to squeeze in.  I for one, am interested in this project, hope it gets more attention especially with the low cost feature. Anyway these are just some ideas, good luck!

Links

https://sourceforge.net/projects/tinypicbootload/

 

this is Ralphd's link for picoboot

https://github.com/nerdralph/picoboot

 

 

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

Thanks for all the suggestions so far. A bit of an update and a few answers to questions...

 

1) This definitely needs a hardware 'thing' of some description. Any form of serial connection to a traditional bootloader is a no-go for plenty of good reasons. It can't rely on any software needing to be installed on someone else's PC/Mac/Linux box.

 

2) The 'thing' has to be so cheap that we can write off the cost should we fail to get them back.

 

So, my current plan...

 

1) Write a bootloader which looks on the 6-pin ISP connectors for an EEPROM and loads flash from that if present. The EEPROM will be I2C. Why? Because the SPI ones appear to use /CS as an active signal. And there's no spare pins in the 6-pin that can function as /CS. I'd plan to use this in everything I do in future.

 

2) For units already in the field a small PCB with an AVR on it which is a simple, bare bones, ISP programmer. It has one job to do.

 

Thanks again.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:

1) Write a bootloader which looks on the 6-pin ISP connectors for an EEPROM and loads flash from that if present. The EEPROM will be I2C. Why? Because the SPI ones appear to use /CS as an active signal. And there's no spare pins in the 6-pin that can function as /CS. I'd plan to use this in everything I do in future.

 

That they do.  I did not know that, so I went and checked.  I plucked one at random from Digikey's web site, and found this buried in the spec sheet:

 

 Every communication session between host and CAT25080/160 [the SPI EEprom in question]
must be preceded by a high to low transition and concluded with a low to high  transition of the CS input.

 

Italics as in original, no less.  Definitely worth noting.  Thanks.  S.

 

PS - If you really want to be silly, blow the RSTDISABL fuse in your bootloader - after all, you don't need it anymore - and use that as /CS...  devil  S.