Firmware update from USB Stick

[elcrcp]

Hey guys, lets say I have a fixed named USB Stick and have a fixed named hex file in it. Again lets say we are working with a 18f2550 and usb bootloader or another pic with uart-usb converter. Doesn't matter at this point.
Is it able to check the usb stick, search for file in it and then load the hex to pic?

A Plug and play firmware update method?
_________________
There is nothing you can't do if you try

[temtronic]

You need a 'Vinculum' type peripheral to read a USB drive, or a PIC with OTG capability (not a 250..). I've done the 1st, years ago for a 'datalogger'. If you want to have a program on the USB FD and 'bootload' it, that's another challenge. The concept is OK..obviously a custom bootloader. I'd suggest a newer PIC, one with lots of memory and 2 hardware UARTs something like the 18F46K22, my goto PIC.
Other who use bootloaders daily will surely reply.
Jay

[Ttelmah]

It is critical to understand the two different types of USB operation.
The standard USB peripheral on a PIC, is a 'slave' device. The USB attaches
to a 'master' like a PC as a basic device, that can then answer requests from
the master supplying data or accepting data. This is distinct from a USB
'master' device. The 2550, is only capable of being a 'slave' device. For a
'master' the PIC as Temtronic says, needs to support USB OTG. Now on
top of this to be a 'master', the code has to provide a USB stack (which
basically scans the bus, and changes state/speed according to the signals
being received from the attached slave, and then changes operation mode
doing enumeration to find out the nature of the slave attached, and then
support the modes required). This makes the 'master' code very large.
Even worse to support a drive, the code then has to also have filesystem
handling (FAT16, FAT32 etc.).
Now PIC 'slave' handling for a PIC like the xx50, is reasonably small.
A complete library for this would use perhaps 6KB. A similar library for a
'master' device including file system handling, will be more like 20KB.
If you are using this as part of a firmware upgrade, this will all be code
that is permanently in the chip and unchangeable. Ugh!....
The Vinculum type device has it's own firmware to do this and talks
to the PIC using serial or SPI. As a result the bootloader can be only a
few bytes larger than a basic serial bootloader.
So if you feel you need to go this way, then follow Jay's suggestion and
look at using a Vinculum adapter. Doing it in the PIC itself, is going to
result in the bootloader being very large indeed, and means you will
have to use a different PIC.

[elcrcp]

Thank you temtronic and Ttelmah. That was very educational. So in short, trying to shove all code to 1 pic would be a waste and memory problematic, we can use second chip with otg capacity as a programmer but coding it also a waste since there are Vinculum chips which are usb-ttl converter chips with usb host and file system support.

Thanks again, I never needed usb host before so I wasn't aware of "Vinculum" chips. I started my day with a new knowledge :D
_________________
There is nothing you can't do if you try

[Ttelmah]

Yes. There is actually another thing I didn't say, which is that the PIC USB
master stack, I have found to be less than reliable!... I've been through
several versions of the MicroChip code for this, and all seem to have issues.
The Vinculum several years ago, was 'poor', but for about the last five
years or more has been superb. On a scale of 0-10, for ease of use and
reliability, I'd rate the USB OTG stack on the PIC as at best a 6. The
Vinculum at 9+. I know which I use now!...

[mdemuth]

Hi,
I am using the SD-memory card interface for updates from https://www.brushelectronics.com.
Now I want to migrate from SD-memory card to USB memory stick using the vinculum chip to access the USB-stick via UART.
The chip I am currently using is a PIC18F46K22.
The solution I am looking for is to manage thhe FW-update by inserting an USB stick with the hex file and then activate the programing sequence out ouf the menue.
Does anybody done this before and/or would like to support me with this (commercial) project.

[temtronic]

Very easy to accomplish, BTDT. One 'trick' I use is to use the date in the FW filenames.'FWdoyV1.hex', FWdoyV2.hex' where FW means FirmWare, doy is the date of year (1-365),V means Version, 1 is 1st, 2 is 2nd, etc.
Store the current (running) FW version filename into PIC's EEPROM.
Depending on the hardware (LCD module, KPD module), the 'menu update' code should show the current version and a scrollable list from the USB stick. Choose the version to upload, confirm, execute.

[elcrcp]

Hi, I'm still working on it and gonna take long before completing, because I built a development board of my own and working on it as a hobby and i can't spare much time as now.
I didn't know about vnc chips but I did some research before starting and viniculum chips has some sample codes that you can work with.
_________________
There is nothing you can't do if you try

[mdemuth]

Hi Temtronic,
I have bought myself a V2DIP1-48. Today I found the time to get this thing going using a simple terminal program. I am able to write and read file etc. The main task is to write and transfer the logged data from the application into the USB memory stick. This problem seems to be solved today.
Now for the loader: Personally I have not much experience on that since I bought the solution from Andrew Smallridge.
I think it can be rather simple:
The loader is located in the first section of the program.
The loader looks if a certain file is in the root directory of the stick e.g. FWxxxx.hex
It can be always the same name . If this file is on the USB stick it will be programmed into the chip.
=> if the reply from the vinculum chip after the DIR command contains "FWxxxx.hex " => PERFORM_FWUPD().
In order to perform a FW update the only thing that has to be done is to insert the USB stick and then reset the µC.

Now I am looking for the particular function PERFORM_FWUPD().

[Ttelmah]

One modification to this.
Have your code able to checksum the code that is in the chip.
Only perform the update if this does not match the checksum of the
file.
If you don't do this and the stick is left in place you risk it repeating
updating code that is already in the chip.....

[temtronic]

There is a problem with...'.It can be always the same name..'.

YOU do not KNOW if the code IS an update....

Also you can't easily confirm what IS different from past versions. You could have 'bad code' in the current version and NOT be able to go back 1-2 versions to 'better' code. Something simple like a 'setpoint' that SHOULD be '32' but you mistyped as '23' in the new version....it'll cause a LOT of head scratching and lost time, trying to figure out why the new code doesn't work.
Jay

[newguy]

Also think about automatic rollback and keeping a copy of the old FW. Sometimes a new FW release will break something. The bootloader should be intelligent enough to realize that something is wrong and automatically roll back to the last known good revision. That requires that the last FW is preserved somewhere (not deleted, not overwritten). There should also be some sort of mechanism for field staff to use to roll back manually. A new FW release might not "brick" the unit, but it might introduce other issues. There needs to be a way for the unit to be safely rolled back in that event. Also note that any automatic update needs to realize that that particular FW release is now deemed "unreliable/suspect" so that your automatic update mechanism will no longer attempt to write that version.

[Ttelmah]

One suggestion, use the last 4 digits of the filename, and store this
in the chip ID bytes. Then simply reading the ID will allow you to know
what file is in the chip. Only write the file if this number is higher than
the stored ID.

[asmallri]