firmware update for WebControl8

Hi Ross,
 
Thanks for your input. Actually, we are talking about 256 bytes RAM we don't have. I am not sure you realize what I was talking about the memory requirement are the amount memory we don't have, not memory we still have available.  We are using the best compiler with extreme optimization to fit current code into the chip.  If a  piece of memory was not in the memory map, code could not branch to it. All the variables compiler must put into memory map so that linker can resolve its memory location. There is no memory management chip to remap another piece of memory. Only stack variables' space can be shared, but if that is not planned well, it will step each other, because one task's stack may not finished working when it is interrupted by another function. 
 
I am sure there are a lot experts on this forum could actually write firmware for the WebControl board. It will be very interesting to see someone coming up an open source project running on WebControl board.  Then anyone can try to fit more code into the chip for fun.
 
CAI_Support said:
We appreciate your input. It is not EEPROM space to store the code, it is RAM totally running out.  There are only 3808 bytes RAM, we don't have even a byte left.  We removed serial port long time ago. TCPIP took close 1K RAM. When we implementing the 3.02.16 features, we started by reducing email queue size, in 3.02.17, we also removed four IP addresses from allowed hosts, we manually massaged ram allocation to fit things in. 
 
To implement the bootloader and encryption, it will need at least 256 bytes RAM that we don't have.  It will need to have a buffer to store reading from the network, decrypt it into another buffer. then write to EEPROM a page at a time.  That EEPROM page size is 256 bytes. Besides, now we squeezed all those code in, we don't want to take out features for this.  Thanks for your helpful suggestion.
 
No bootloader runs as separate application so you have full RAM since main application is not running at the same time.  You only need program space: 8K.
 
Thanks for your input. We have bootloader implemented in the 32bit board, which does take both RAM and ROM. Maybe that has something to do with the TCP stack implemented in our CPU brand,  When bootloader running, it does not run the other part firmware. However, the main firmware running, it must be able to switch to bootloader.  The reason is that when board is configured on certain IP address, bootloader must use that IP address. Thus linker must link those two parts together.
 
This is not a limitation. The main program simply writes out the network config to a known (by the bootloader) RAM address (it can be anything because the next instruction is to start the bootloader so you can't corrupt anything). Then the bootloader starts and has control of all the RAM. After the program memory is updated by the bootloader it then starts the main program again and releases all RAM to it. I have done it. They are completely separate and it works fine. :) If you have enough EEPROM to store the new image you can make the bootloader much smaller than 8K. You can copy to EEPROM from ethernet memory with very small buffers and you can dynamically resize TCP buffers. Plenty of options.
 
Sounds very interesting, do you like to send us your bootloader's code for us to reference? We could pay you something or exchange for some boards.  If you are interested, please send us message or email directly.
Bootloader and application are two separate images that combined write to the chip. They have to share MAC address, and IP configurations.  Some of them stored inside CPU and configuration stored in the external chip.
 
Thanks to the help from az1324,  we now have bootloader on WebControl8.  All current shipped boards are already loaded with the bootloader.  The running firmware is still 3.02.17d with no feature or function change from boards shipped in last 3 months.
 
Bootloader will allow future update to be done over the network, without the need for shipping them back.  Boards purchased in the past without bootloader  still need to send back if firmware update is required.  Bootloader only works on hw rev 2.2.2 boards.
 
CAI_Support said:
Thanks to the help from az1324,  we now have bootloader on WebControl8.  All current shipped boards are already loaded with the bootloader.  The running firmware is still 3.02.17d with no feature or function change from boards shipped in last 3 months.
 
Bootloader will allow future update to be done over the network, without the need for shipping them back.  Boards purchased in the past without bootloader  still need to send back if firmware update is required.  Bootloader only works on hw rev 2.2.2 boards.
 
That's fantastic news, guys - and will spur me on to finally get my boards back for upgrade!
 
CAI_Support said:
 All current shipped boards are already loaded with the bootloader.  The running firmware is still 3.02.17d with no feature or function change from boards shipped in last 3 months.
 
Good news being able to update firmware in the field. I have a couple of question. It sounds like there are two versions of rev 3.02.17d, one with and one without the boot loader. It that correct? If so how does a customer know which version they have? Since firmware is able to be updated remotely I assume there is a control option to enable and disable this feature for security.
 
Tom,
 
The firmware version reflect any feature addition and function change, or bug fix. From the one with bootload to earlier non-bootlader version, they are no function or feature change, nor bug fix. So we decide to stay on same firmware version number.  In the
/api/status.xml
there is a field showing build date. The one build in May was the one without bootloader, the one build in JUly is the one with bootloader. 
Another way to distinguish is during booting. Bootloader will blink the green LED for four seconds on the network socket, the one without bootloader will not blink solid green when network detected.
 
great news! Nice to see companies open to new ideas.  I can't take my current setup down long enough to send it in, but I might buy a new one now for the new features and upgradeability.  and to have a spare :) 
 
Since you are going to release the firmware over the web, would there be a way to get the firmware upgraded via Microchip programmer (ie. PickIt2 or Pickit3) for people that have the know-how to? We are about to move a few dozen into place and there is no way we could not send them back for upgrade. We just purchased them and they show 09/05/2013 and v03.02.17d.
 
Alex
 
AlexHK said:
Since you are going to release the firmware over the web, would there be a way to get the firmware upgraded via Microchip programmer (ie. PickIt2 or Pickit3) for people that have the know-how to? We are about to move a few dozen into place and there is no way we could not send them back for upgrade. We just purchased them and they show 09/05/2013 and v03.02.17d.
 
Alex
 
You are missing the fact that the firmware release is encrypted.  That is much different than releasing the raw firmware file.
 
AlexHK said:
Since you are going to release the firmware over the web, would there be a way to get the firmware upgraded via Microchip programmer (ie. PickIt2 or Pickit3) for people that have the know-how to? We are about to move a few dozen into place and there is no way we could not send them back for upgrade. We just purchased them and they show 09/05/2013 and v03.02.17d.
 
Alex
Hi Alex, if you just purchased them, your probably has bootloader already.  Try to use browser to run this command:
http://ip-address/bootloader.cgi?start
 
If your board stopped running, the board already has bootloader, you can update to the latest without problem.
http://www.cainetworks.com/support/how-to-update.html
 
Back
Top