General Requirements for PC Application to Perform FOTA Update

What is required for a PC application to update an RSL10 through FOTA? I can perform FOTA updates using Fota.Console and the RSL10 Bluetooth Low Energy Explorer. Now I’d like to extend that capability to the desktop application I’m developing. Unlike onsemi’s programs, my application isn’t written in C# and .NET, and it uses the computer’s default adapter, so it doesn’t make use of the RSL10 dongle. I use a BLE library that can:

  • Scan
  • Connect
  • List services and characteristics
  • Read from and write to characteristics
  • Notify

Where can I find a general procedure that outlines the necessary interactions between the PC and the RSL10? For example:

  • Are signatures or headers used?
  • How is the binary file itself sent?
  • What starts the new app once it has been uploaded?

@matthew.s

  1. Take a look at the FOTA Console and FOTA Lib source code provided in the BLE_Explorer_Samples.zip.
    By taking a look at FirmwareImage.cs you can understand how the parsing of the binary image is done. FotaController.cs is responsible for transmitting the image.

  2. The BLE_Explorer_Samples.zip also contains Doxygen based documentation.

  3. In addition look at the Bootloader and firmware fota lib and documentation. The bootloader sample is responsible for starting the app once it’s uploaded.

  4. If you want some other examples of performing FOTA on the central side, you can request a copy of the RSL FOTA Android and iOS source code through your local sales team.

Thank you for using our community forum!

@martin.bela

Thanks for your recommendations. I translated some of the classes from the source for Fota.Console into Python3, and I’m now able to parse the fota file. My program can also connect to ‘ON FOTA RSL10’, read the device ID, build ID, etc., and write to the data characteristic. Fota.Console mostly makes sense to me, but, having never used C# before, I’m still unsure about how the bytes are transmitted.

In Fota.Console.log, each group of transmitted bytes appears in the following order:

  1. Task started (GATT Write Command (Connection:0x00 Handle:0x000B <...> ))
  2. TX - ID:GATTC_WRITE_CMD(0x0C0A) Source:TASK_ID_APP(0) Destination:TASK_ID_GATTC(0) Parameters: 0x0D0100000B000000F4000000<...>
  3. GATT Write Command (Connection:0x00 Handle:0x000B <...> )
  4. Task 'GATT Write Command (Connection:0x00 Handle:0x000B <...> )' completed (Result:Success)
  • What transformations did the byte array containing the image data have to go through to appear as it does in the log file? Is HDLC or COBS used here?
  • What is the purpose of 0x0D0100000B000000F4000000 in front of the data in step 2? And what is the purpose of step 2?
  • Is the data characteristic solely responsible for receiving the image, or are lower level communications necessary?

Hi @matthew.s ,
Q1) What transformations did the byte array containing the image data have to go through to appear as it does in the log file? Is HDLC or COBS used here?
Answer) The data bytes are encoded using the Consistent Overhead Byte Stuffing algorithm.
For information take a look at the Transmit method in CobsFraming.cs, where you can see that the data is appended with the CRC and then encoded using COBS algorithm.
At the end, encoded data is added to the CobsFraming.sendBuffer, where the sendBuffer is prepended and appended by 0x00.
For information regarding COBS take a look at Consistent Overhead Byte Stuffing - Wikipedia.

Q2) What is the purpose of 0x0D0100000B000000F4000000 in front of the data in step 2? And what is the purpose of step 2?
Answer) It is just log information about the entire dongle frame object passed to the OnSemi.RSL10.Driver.Dongle.TransmitFrame(Frame frame) method.
The protected Start() method of the TaskGattWrite.cs class in the OnSemi.
RSL10.Adapter.dll makes use of this method. OnSemi.RSL10.Driver.Frame.Frame(MessageId id, TaskId sourceTask, TaskId destinationTask, IEncodable parameterObject) creates a frame object with parameter object.
image

For the parameterObject in the Frame object we pass the OnSemi.RSL10.Driver.Ceva.GattcWriteCmd.GattcWriteCmd(GattcOperation operation, byte autoExecute, UInt16 seqNum, UInt16 handle, UInt16 offset, UInt16 length, UInt16 cursor, ByteArray value).
image

The additional values that you see in step 2 come from these parameter before the ByteArray.
For more information, take a look at the doc folder in BLE_Explorer_Samples.zip.

Q3) Is the data characteristic solely responsible for receiving the image, or are lower level communications necessary?
Answer) Lower level communication is necessary.