CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Firmware update from USB Stick

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
elcrcp



Joined: 11 Mar 2016
Posts: 49
Location: izmir / Turkey

View user's profile Send private message

Firmware update from USB Stick
PostPosted: Mon Dec 09, 2019 3:18 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 7349
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Dec 09, 2019 7:50 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Tue Dec 10, 2019 1:02 am     Reply with quote

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



Joined: 11 Mar 2016
Posts: 49
Location: izmir / Turkey

View user's profile Send private message

PostPosted: Tue Dec 10, 2019 1:46 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Tue Dec 10, 2019 1:56 am     Reply with quote

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!... Very Happy
mdemuth



Joined: 16 Apr 2007
Posts: 62
Location: Stuttgart, Germany

View user's profile Send private message Visit poster's website

Update?
PostPosted: Mon Mar 16, 2020 1:29 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 7349
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Mar 16, 2020 5:17 am     Reply with quote

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



Joined: 11 Mar 2016
Posts: 49
Location: izmir / Turkey

View user's profile Send private message

PostPosted: Mon Mar 16, 2020 6:32 am     Reply with quote

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



Joined: 16 Apr 2007
Posts: 62
Location: Stuttgart, Germany

View user's profile Send private message Visit poster's website

PostPosted: Mon Mar 16, 2020 9:17 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Mon Mar 16, 2020 9:21 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 7349
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Mar 16, 2020 9:33 am     Reply with quote

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



Joined: 24 Jun 2004
Posts: 1663
Location: Edmonton, Alberta

View user's profile Send private message

PostPosted: Mon Mar 16, 2020 10:23 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 15723

View user's profile Send private message

PostPosted: Mon Mar 16, 2020 10:45 am     Reply with quote

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



Joined: 12 Aug 2004
Posts: 1592
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Mon Mar 16, 2020 9:24 pm     Reply with quote

mdemuth wrote:
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().


Hi,

If you already have my SD card bootloader and can now read and write files via USB then you already have all the code you need to port the SD bootloader to your needs. Additionally, if you are using the encrypted SD bootloader you will be able to use this with your USB implementation.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group