Firmware Update

If you have a simple question and just want an answer.
Post Reply
User avatar
xaerox
Active Member
Posts: 43
Joined: Thu Apr 30, 2015 6:12 pm

Firmware Update

Post by xaerox »

Hello everybody,
is it possible, to do firmware updates via WiFi controlled by an Smartphone app?
My own designed system is designed with audio inputs and outputs an a WiFi-Chip (TiWi-SL). For future projects I would like to do simple firmware updates directly on XEF216-512-TQ128.
Maybe there's a way to do it with 2 different flash. One with the firmware-update-software an one, where the current firmware will be updated.
Are there any ideas?

I hope you understand my problem.
Best regards,
Thomas


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Allow me to throw out some ideas :)

The XMOS CPU you are using is the XEF prefix so the flash is internal to the device.

Respectively, the following short note from XMOS that states that it is possible to assert RESET line to park this CPU into tri-state (hi-z) mode so that you can assert the required signals onto the QSPI pins to reflash the internal flash using an external SPI bus master.

https://www.xmos.com/download/private/G ... 283%29.pdf

Keeping in mind that, in theory, it should be possible to also program the same target flash device using SPI mode access (rather than QSPI mode), you could use very low cost CPU devices to perform this task. For example, EFM8 (Silabs) is $0.20 USD and many STM32 devices are also under $1 USD if not $ 0.50 USD each.

The higher end CPU devices from ST and others offer QSPI mode which will greatly reduce the programming time of this internal flash device.

So the idea would be to use your WIFI module to read the remote firmware and program another flash device onboard your design. After this programming of "spare" flash device, perform a CRC check to ensure the flash is not corrupted. Then signal the external low cost SPI master CPU to take over. This external CPU will then park the XMOS device into RESET and transfer the fresh flash image into the XMOS device using the same SPI pins and then release control back to the XMOS CPU till next time.

It is possible to bit-bang firmware into a freshly soldered EFM8 device - we are doing this now with our PCIe design and using GPIO pins to upload firmware from the host CPU. Silabs offers a note AN127 on how to do this but if you do this, please review our raised bug report on this case. It took us over 3 weeks to properly program the EFM8 (blank) due to lack of proper routines in the Silabs appnote. The proper appnote is from Cygnal and was found on a Russian website (as it is old - Silabs bought out Cygnal). We have the same appnote posted on our company server.

https://www.silabs.com/community/mcu/8- ... _date-Exiv

The key question you must keep asking is, what if xx scenario surfaces? Will that scenario brick your widget? Very important to be 110% sure before proceeding to erase the firmware inside your gadget.

Just sharing some thoughts..
User avatar
xaerox
Active Member
Posts: 43
Joined: Thu Apr 30, 2015 6:12 pm

Post by xaerox »

Hi mon2,
thank you for sharing you ideas! It's sound really useful for me.
I just want to reflect your main idea. Later In future work I'll create another board maybe using a XUF208-256-TQ64 and a SPI WiFi Chip like the TiWi-SL chip. This is our main construction to send Data to my homeserver. For doing Updates, so that's your idea, another SPI CPU will be attached, which is doing the firmware update on XMOS. I dont understand, how the external SPI-CPU will get the new Firmware sent from homeserver via WiFi to the XMOS. I think the problem is, that the wifi-chip is connected to the xmos chip. The SPI-CPU has no direct connection to the wifi-module.

Hope you understand my question.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. I think we will be soon in a similar case and require a method to offer field upgrades with a solid solution. Working on a complete eco system for home automation but still working out the building blocks.

I think you have many potential ideas you can follow so will give it more thought but for the immediate feedback:

1) Your XMOS device is currently the SPI master. This SPI master is chatting with your WIFI module. It should be very possible to allow for the same SPI master to select an alternate SPI flash. So, the XMOS code will use your WIFI module to read in the new firmware and then copy this firmware onto the alternate spare flash device. Once the firmware is considered to be uploaded onto this alternate flash device, perform a CRC validation to be sure the firmware is 100% correct.

2) After a positive verification, signal the external low cost alternate SPI master (EFM8, STM8, STM32, etc - all under $1 USD). Then this external CPU will take over the same SPI bus and place the XMOS into RESET. Then this new SPI master will copy the alternate SPI flash contents and apply into the XMOS device using the pins defined by XMOS (ie. you are parking the XMOS CPU into reset = hi-z and can now assert external logic levels while the XMOS device remains parked via the RESET pin). Once the new firmware is loaded, release the reset of the XMOS CPU to run off the new firmware.

This convoluted method should work fine but needs to be carefully thought out and may require the use of muxes (ie. to steer the SPI flash between the XMOS CPU and the next SPI master). The key benefit of this approach is that you can erase the entire internal flash of the XMOS CPU since the external SPI programmer (EFM8, etc.) can insert the code from scratch.

These are just ideas and there are others that may be more practical.

3) While driving to work, thinking about - how large is the internal flash inside your XMOS CPU? How much is free after your code? If there is enough spare room, you could just download over wifi the new firmware, apply into the free space of your flash device and then reboot. This is the DFU method where if the 2nd image is properly stored into the flash, the ROM inside the XMOS CPU should allow to boot off the 2nd image. However, this method is restricted to the amount of spare room left inside the flash device.

If you are designing a new product - consider to leave room for a proper footprint of the flash device for EXTERNAL use. Then you can purchase XMOS CPU without internal flash (if practical) but can be as large in density as you wish. That is the approach we would take. Internal flash is great but limited to what the factory gives you, better to use an external flash so you can grow as your code size expands. The key here is that the single flash device could hold multiple copies of your firmware.

Again, just ideas so take the approach that is best suited for your project. Based on costs, believe the external (larger) flash idea may be the winner with DFU.

The use of the external SPI programmer CPU is very possible but you will then need to review how to program this fresh and new CPU? For EFM8, we wrote our own code to program in-circuit after soldering. Or you may need to apply external JTAG pins for the CPU (ie. SWD for STM32 devices) so you can program the micro using pogo pins. But, what if you wish to change this external CPU's code? For this reason, you will need to make the XMOS CPU act like a programmer for EFM8 / STM32 or whatever CPU you have in mind.

https://www.xmos.com/published/dfu-user-guide

The summary of the external CPU idea is that this extra logic is acting like a dedicated SPI programmer that you will be including onboard.
User avatar
xaerox
Active Member
Posts: 43
Joined: Thu Apr 30, 2015 6:12 pm

Post by xaerox »

Hi mon2,
thank you very much for you ideas. It seems, that the solution with the bigger external flash and DFU is most attractive.
Do I have to change the xn-file, to give the XMOS cpu the information for more flash or is it not necessary?
I'll read the dfu user guide tonight for planning the new hardware-and software combination.

One another question: For data security, I would save internal data on external flash. Is ist possible, to use more SPI-Master e.g. accessing wifi-module, boot flash and another data flash? Some data (not really privacy data) will be saved on flash and I want to secure it from hackers in the network connected with the internet.

Again, thank you very much!
Thomas
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

The XEF216-512-TQ128 contains a built in 2MB flash. Assuming you're not planning on doing anything like booting many different images or reprogramming one of the tiles dynamically (I don't even know if this is possible) then a typical application shouldn't need more than about 256kB of flash (since the XEF216-512 contains only 512kB of SRAM for code, data, and stack). I suppose you could have large lookup tables in the flash but even so I would suspect that if you are only running 1 image and storing an upgrade image you could store all the other data you would need -- unless you are doing serious data logging.
User avatar
xaerox
Active Member
Posts: 43
Joined: Thu Apr 30, 2015 6:12 pm

Post by xaerox »

Thank you akp,
I found the flashlib on xcore git which also can be used for loading the new factory image. I would test it out.
Best, Thomas
Post Reply