Field Upgrades

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

In a previous topic...

 

http://www.avrfreaks.net/forum/b...

 

...I mentioned that I'm often having to support the field upgrade of software. In the final post of that thread I wondered about connecting an SPI EEPROM to the ISP connector and running a bootloader. The issue has come around again and it's now worth a serious look.

 

It needs to be a cheap solution whereby we can just mail out something physical in the mail and not worry if we don't get it back.

 

My initial thought was that as I fit a standard ISP connector to all my boards I have access to the SPI bus, power, ground and reset. Make a simple PCB with nothing more than a cheap 32k x 8 (for example) SPI EEPROM and a ribbon ending in a 6-pin female header and have a bootloader on the AVR look for the external EEPROM and then bootload from it. You'd need to do version and compatibility checks but that's easily do-able with embedded text strings. A quick calculation shows that I can build those for well under 5 pounds/dollars/euros.

 

The problem I've come across is that all the SPI EEPROMs I've found so far need /CS as well and rely on /CS toggling to initiate transfers of data. I'd prefer to use SPI as it has the least code size requirements making it easy to fit in a bootloader.

 

So, problem 1 is 'How could I add /CS to an existing 6-pin ISP?'. I'm doodling ideas around generating it on the dongle with some sort of capacitive arrangement from one of the other lines but it's not looking feasible

.

The other option is to go I2C. The dongle costs would be the same (well, two extra resistors) but I'd bit-bang an I2C bus using the SPI pins.

 

 

Thoughts? This seems to come up with other people from time to time needing a cheap production/field programming solution.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

Add an SD/MMC card socket to the design. Mail them a card when they need an update.

 

[Shameless self promotion = ON]

 

https://spaces.microchip.com/gf/...

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

clawson wrote:

Add an SD/MMC card socket to the design. Mail them a card when they need an update.

 

SD/MMC would certainly be easier at this end, or at my customers end for them to mail out. And I have played with your SD Bootloader. It's just that I'm trying to avoid adding anything extra to the main unit. By using the existing ISP connector it's a 'free' feature on all units; only a small percentage ever need an upgrade.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

Use reset port as CS in ISP conn for SPI EEPROM. You don't need to re-flash the whole code anyway. Just for upgrade?
.
MG

I don't know why I'm still doing this hobby

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

I always try to avoid disabling the RESET pin; it just feels like a good way to shoot yourself in the foot.

 

A careful read of the EEPROM reveals something interesting. It's only writes that really really need an active /CS. When reading it looks like you only need one transition on it right at the start which can be done with an RC delay from the VCC rail. There is a downside in that if you get out of step you stay out of step but a CRC check at the end should sort that.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

Well... looks like I2C using bit bang SPI is the reasonable choice. Since no UART conn in the board. Maybe you should include it in the next design?
.
MG

I don't know why I'm still doing this hobby

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

What about using alank2's little programmer?  YOU can send that out, and they connect it to the ISP port and it does the rest.  Thats what I do and its pretty straightforward.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

jgmdesign wrote:

What about using alank2's little programmer?  YOU can send that out, and they connect it to the ISP port and it does the rest.  Thats what I do and its pretty straightforward.

 

I've got a pile of the Kanda keyfobs already. The problem is...

 

a) Quantities. It's rare to need to do more than the odd one or two upgrades but I need to plan for doing a dozen or more at a time. That's quite an investment in keyfobs.

2) Returns. Or rather lack of. I can afford to lose the odd 5$/£5 unit but not a keyfob or two.

 

It looks like I2C might be the way to go.

 

The complete BOM for an I2C on a PCB with a flying 6-pin socket is under $2/£2.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

jgmdesign wrote:
What about using alank2's little programmer?
+1yes

 

David (aka frog_jr)

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

@Brian,

Good points made.  I can understand the need for something inexpensive.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Brian Fairchild wrote:
When reading it looks like you only need one transition on it [/CS] right at the start which can be done with an RC delay from the VCC rail.
or a CPLD or GreenPAK™.

GreenPAK is inexpensive though at 0.5USD programmed each for 3000 will increase the price of that board by about 2USD.

Hope Torby will pipe in and say that's tinyAVR country wink

 

http://www.silego.com/products/greenpak.html

http://www.silego.com/buy/index.php?main_page=product_info&cPath=67&products_id=474

 

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

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

gchapman wrote:

Hope Torby will pipe in and say that's tinyAVR country wink

 

If there was a tiny, in an 8-pin package, with 32k of Flash then life would be wonderful.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

You could buy a load of Chinese STLink dongles. They have sufficient Flash to store multiple 32k binaries. They come with a sexy little case. But you would need to produce a suitable ribbon cable to match your ISP header.
.
David.

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

You could just require the customer to purchase the new (improved) version that has additional new functions and/or features (bug fixes). smiley

Much better cashflow that way!

 

Jim

 

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

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

Last Edited: Tue. Oct 10, 2017 - 01:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian,

I thought about your situation and I came up with two possible solutions....

 

Option 1) Can you remove the Vtg connection and connect the now unused pin on the ISP to a pin on the AVR to function as a /CS line?  When you do an ISP you would have to make an adapter that would have a small lead coming off of it to connect to the boards VTG.  This may not be ideal, but it would certainly give you the full SPI, and the /CS you are looking for.

 

Option 2) Not a 'clean' solution but can you 'dual purpose' the VtG pin with a solder jumper?  BAsically what I am thinking is bring the Vtg pin to a solder pad, then have two other pads...one going to the boards Vcc, the other to a pin on teh AVR for /CS use.  During production the Vtg pin on the ISP port is connected to Vcc, after programming and verification remove the jumper and add one for /CS

 

Of the two options I think Option #1 is the better of the two as it does not require any soldering, and as such human error.

 

Just my two pence,

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I would imagine Brian wants to use the Vtarget pin for powering the I2C or SPI EEPROM.

 

Quebracho seems to be the hardest wood.

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

John_A_Brown wrote:

I would imagine Brian wants to use the Vtarget pin for powering the I2C or SPI EEPROM.

 

Guess I didn't think hard enough....blush

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

    You start by setting MOSI pin low before enabling the SPI (no clock). Then immediately turn the SPI on and to the job. Make sure you send zeroes when sending dummy bytes to run the clock line for reading. If you want to deselect the EPROM simply keep quiet with MOSI high.

 

    Personally I would take another approach. I would bitbang a classic UART based bootloader with autobaud and provide the customer a FTDi cable or equivalent. These days who does not have a notebook for a such event. And this gives you speed, I mean, you write the update and send it via e-mail. Otherwise you need to deal with the hassle to build the boards, and to program them and ship. Let them buy a cheap cable on eBay or so. Wouldn't be a smart move to be able to use that header for both ISP and bootloader ?

By using the existing ISP connector it's a 'free' feature on all units

    That programming header is not for free in there. You can better manage your projects and not to have it in there, or at most just pads for pogo pins or pads at the edge of the board for a card edge connector.

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

Back before I developed the autoprogrammer, I had a very crudely made 328 that could upgrade the firmware of another 328 project I had.  It could only do this because I used compression on the firmware to be programmed, and while it does not compress much, it was enough.  It was basically a 328 with a couple of supporting parts, cap, reset pullup.  The real PITA about it was that I had to go through an entire process of compressing and embedding and then compiling the firmware into the programmer I wanted it to flash so it could flash the out in the field units.  To say it was not intuitive or easy to use is an understatement.  (At least for me, the customer just had to touch it to the programming port and the LED would blink until it goes solid!)

 

 

Or are you thinking of using a DIP EEPROM and a bootloader on your device to check for it and update itself?

 

Are you concerned about security?  I once had this thought that you could supply two checksums and a one time pad XOR stream from the old firmware to the new firmware.  The bootloader which is privy to the existing flash would read it any verify the checksum and at the same time XORing it with the XOR stream and verify the new checksum.  If both are good, then it can XOR the flash for real changing the old firmware to the new firmware and give validation that all went well.  It would require that the old version is a specific one unless you provided multiple XOR streams for each version you wanted to upgrade.

 

Good luck!

Last Edited: Wed. Oct 11, 2017 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:

Or are you thinking of using a DIP EEPROM and a bootloader on your device to check for it and update itself?

 

That's my current plan. I've got some bits on order to try.

 

Option 1 is...

 

32k x 8 SPI EEPROM on a small board with a flying 6-pin connector

Bootloader in main AVR

Reset controller in a TO92 package to deal with /CS on the EEPROM <-might not be needed

 

...SPI EPPROM because it has the simplest code requirements.

 

If that doesn't work then Option 2 is...

 

32k x 8 I2C EEPROM on a small board with a flying 6-pin connector

Bootloader in main AVR

Reset controller in a TO92 package to deal with /CS on the EEPROM <-might not be needed

 

 

alank2 wrote:

Back before I developed the autoprogrammer, I had a very crudely made 328 that could upgrade the firmware of another 328 project I had.

 

I thought about something similar but found like you that compression is a PITA.

 

However, I've just realised that a tiny 45/85 on a board with a 32k x 8 SPI EEPROM would work as a dedicated dongle programmer.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

Yep a tiny would do nicely.  You are trading writing a bootloader for writing the tiny code, but both approaches would work.

 

I can't think of anything cheaper than my 100mil header inline connector either.  You just put it through the holes and put at a slightly angle to make good contact on all pins.  You can't do that with a 2x3 arrangement, and the holes can be accessed top side or bottom side with no problems.  Just have to mark pin 1 properly.

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

I would use a 1x7 connector, with GND on pins 1 and 7, and VCC on pin 4.  That way, the end user couldn't fry anything by plugging it in backwards.  It wouldn't work, but it wouldn't die.

 

You didn't answer if you were concerned with security.  An SPI programmer could be fooled into giving up the app payload.  A bootloader can be made secure.  See AVR231.

 

But I too like the idea of bitbanging a UART and providing a usb->TTL cable, and a (secure) image, maybe wrapped in a script with avrdude.

 

EDIT: productive spooling

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

Last Edited: Thu. Oct 12, 2017 - 03:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
device          miso  vcc   sck   mosi  reset gnd
                v     |     ^     ^     ^     |
prog            miso  vcc   sck   mosi  reset gnd

 

now, reversing it would yield:

 

device          miso  vcc   sck   mosi  reset gnd
                v     |     ^     ^     ^     |
prog            gnd   reset mosi  sck   vcc   miso

 

The first thing a programmer does is look at the voltage on vcc, which it would read reset and get likely the right voltage.

 

Then it will try to pull reset down, which is pulling VCC down!  But what of the ground?  I suppose if miso is output low that would be a problem!

 

I've never had an issue or seen damage from using this exact setup.  I've probably gotten it backwards at least a few times!

 

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

I wasn't clear.  I was referring to Brian's original (current?) plan of using only an external SPI EEPROM, not with an external programmer.  And remember, he intends to power the EEPROM from the device, not the other way around.  How will the EEPROM like being powered out of spec via the AVR's pull-up on /RESET?  Now how will it like it when the bootloader starts wiggling SCK and MOSI?  Perhaps the voltage drop on /RESET due to the EEPROM would keep the AVR in reset, perhaps not.  Why risk it.  Make another hole in the product's PCB, and put another pin on the dongle's.  The bootloader would still be wiggling SCK and MOSI, but the EEPROM would be properly powered.  The result should merely be unsuccessful comms.

 

Nevertheless, I also mentioned I agree with @angelu:  forget SPI/EEPROM.  Bit-bang a USART.  Ralphd managed a (anaemic, but) complete bit-banged UART bootloader in 64 bytes.  Surely it couldn't cost you much to do something similar.  Then >>all<< of your other challenges fall away completely.  Nothing to build, nothing to ship, no issues with double-duty on /RESET.  Email a (preferably encrypted) firmware image (perhaps with an avrdude+script wrapper) to the client, they buy a $3 USB->TTL cable (or you ship them same, still cheaper and less hassle than a purpose-built dongle), and you're done.

 

The biggest question remaining is what to make for dinner.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

Brian Fairchild wrote:
2) Returns. Or rather lack of. I can afford to lose the odd 5$/£5 unit but not a keyfob or two.
The following is for de-bricking an AMD embedded server; price is 3USD :

PC Engines Home

PC Engines GmbH

spi1a

Flash recovery board for apu2

http://www.pcengines.ch/spi1a.htm

SPI CS is generated by glue logic from the interface's signals.

 

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