we’re looking to deploy a solution that uses an android phone + wixel to make local proprietary radio data available in the cloud. This uses an android phone and USB OTG cable. This works great for getting data off the wixel with the COM port, but we are thinking about dealing with wixel firmware updates, and the nicest option for users would be if the android app could handle that - e.g. we use some system (maybe google play etc) to update the android app, and it can deploy a new wixel image (embedded resource in the android app) when the wixel is plugged in.
So to do this, we would need to emulate the WixelConfig app in android, send the special USB commands to place the unit in bootloader mode, and upload the new image etc.
Is there any documentation that could assist with this?
We just wrote a description of the Wixel USB Bootloader’s protocol, and you can find it in the “Bootloader Protocol” section of the Wixel user’s guide.
To use this protocol you will have to get the Wixel into bootloader mode. The procedure for getting the Wixel into bootloader mode depends on design of your app. If you are using our usb_cdc_acm library then you just have to open up the virtual COM port and set the baud rate to 333 to trigger a jump to bootloader mode.
is it necessary to erase the entire image when replacing it?
e.g. could the process be (to replace firmware)
- set to bootloader mode
- erase first flash page (this makes it safe to do whatever, since then bootloader won’t try to load app)
- write new app, with first block last write.
We don’t need to read any flash pages first do we.
Also if we want to load from a .wxl file that we embed as a resource, we just strip everything out except the code section, and that’s just a straight hex/ascii to binary conversion (2:1) correct? we won’t need any settable parameters.
Thanks for your help.
There is no particular order that you have to make the requests, so you could make the requests in the order you proposed, and you do not have to use the Read Flash request. The WXL file contains an Intel HEX file and the format is documented here.
I saw some other comment that flash cannot be written to unless it’s all 1s already, so we need to erase all blocks we will write to first?
Also, I see one of the outputs of the build process is a .hex file. Can we use this, but just adjust the offsets? When we write to flash, do we just write the raw hex file format, or do we need to decode each line and package that up as a write to a page as binary?
sorry for the dumb questions.
Yes, you will need to erase before writing because a write operation cannot change a 0 to a 1.
You will need to understand the format of the HEX file and decode it in your software. You don’t necessarily need to have a one-to-one correspondence between HEX file lines and Write Flash Block requests. You just need to make sure that all the values specified in the HEX file eventually get written to the proper locations.
If you don’t want to write code to parse a HEX file, you might consider using a program like objcopy (which comes with gcc) to convert the HEX file to a binary file, and then distribute the binary file in your Android application instead of the HEX file.