• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 178 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2340R5: FOTA OAD Flow from Internal developed Mobile Application

Debasish Paul
Prodigy 20 points
Part Number: CC2340R5

Tool/software:

I am developing Mobile Application in android that will enable FOTA from application to CC2340R5 module. For that I am following all the steps defined on the website BLE-Stack OAD Profile — SimpleLinkTm Low Power F3 SDK BLE5-Stack User's Guide 9.11.00 documentation, 

After sending the image header the response is coming as OAD_Success("00").

After the response I am requesting for the Block Size. The response is coming as F0 (240 bytes).

Now if I am trying to split the image as a 240byes of chunks and sending by adding the header of 4 bytes, after the 1st packet I am getting error response as [12 03 00 00 00 00] (OAD_BUFFER_OFL)

if I am splitting the chunks as 236 bytes of chunks, it is accepting and transmitting 793 packets out of 797 packets. on 794th packet the response is coming as [12 03 00 00 00 00] (OAD_BUFFER_OFL)

I am also attaching the screenshot for your reference.

so, my question is why it is coming like that? are there any extra bytes at the last of the image file, that we have to handle separately?  

  • 0
    TI__Expert 5120 points

    Hi !

    Could you give us more details about your situation ?
    From what I understand you're using a desktop Java software on your bluetooth-enabled PC to update the firmware of your CC2340R5 using OAD, correct ?

    Here are some debugging steps you could try in the meanwhile :
    - Are you seeing the same behavior when trying to update the basic_ble OAD example from our SDK using your Java application ? Here is a guide on how to setup this OAD example to try this debugging step.
    - In addition to this example, do you know if you are able to update your firmware using our SimpleLink Connect application from a phone ?

    Kind regards,
    Maxence

  • 0 in reply to Maxence Mathieu
    Prodigy 20 points

    Hi !

    Thank you for your reply,

    Actually, I am currently developing an Android application that performs OAD (Over-the-Air Download) to a connected CC2340R5 module. I'd like to outline the process I'm following and the issue I am facing during the image upload:

    1. I begin by requesting the block size from the module.

    2. The module responds with "F0" (240 bytes).

    3. I then send the first 64 bytes of the image header.

    4. The module responds with "00", indicating OAD_SUCCESS.

    5. I split the image file into packets, each containing 236 bytes of image data (i.e., 240 bytes total per packet including the 4-byte header).

    6. With the selected .bin file, I get 797 packets in total.

    I proceed to send each packet with the appropriate 4-byte of header. The module correctly acknowledges each packet and provides the next expected block number in response.

    However, when I send packet number 794, I receive an OAD_BUFFER_OFL (buffer overflow) response. This happens consistently, even though the packet size and sequence appear to be correct.

    - In addition, I have tried with SimpleLink Connect Application, and I found it is working absolutely fine.

    Could you please advise if there are any limitations or configuration parameters related to the maximum number of image blocks or internal buffer sizes that might be causing this issue?

    Any guidance on how to resolve or further debug this would be greatly appreciated.

  • +1 in reply to Debasish Paul
    TI__Expert 5120 points

    Hi !

    I think there are two ways you could solve your issue :

    First, you could look at the source code for the SimpleLink Connect Application, since the application is open source. The files that would be the most interesting to explore in your case would be the ones in the FwUpdate folder, as they contain the code for the OAD.

    Next, you could see how OAD is performed by looking at the raw packets sent to perform OAD. One way is to use a BLE sniffer, but the way I would recommend the most is to use BTool for this. BTool is a software that can perform OAD and that will display every packet sent and received by the device performing OAD. We have SimpleLink Academy Training on OAD that explains how to use BTool to perform OAD on the CC2340R5, and you will be able to see all of the packets sent in the console.

    Kind regards,
    Maxence