• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 373 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.

CC2640R2F: Custom Firmware Update through Serial Bus

SenseGiz Team
Expert 1800 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC3200

Hello Team,

We are using CC2640R2F launch pad, and we are working on Firmware update(Serial Bootloader) from the Server using UART communication.

We are sending Serial Bus Commands to the launch-pad, wherein we are getting proper response as "00 CC". But when we send the actual calculated firmware data (0bf7210001E00000000de8) to the launch-pad we are getting negative acknowledgement (00 33) response. 

We have also tried sending data in the HEX and ASCII format through server. We have some queries on the same:

1. In bootloader mode, what is the data format it accepts?

2. If the format is ASCII, then how to send data above 127 ASCII limit? Consider we have 4F as value it is exceeding 127 ASCII limit.

We have also tried sending the above same data (0bf7210001E00000000de8) through UART to the launch pad by enabling the option Send As HEX it is reaching properly and getting correct acknowledgment as 00 CC.

Launch PAD: CC2640R2F

SDK: 3.1 stack Multi role.

Using: Intel HEX file format.

We are referring CC13x2, CC26x2 SimpleLinkTm Wireless MCU Technical Reference Manual (Rev. D) document.

Please let us know if you need any further information from our side.

Thanks & Regards,

Akash

  • 0 in reply to FI
    Expert 1800 points

    Thanks for your response.

    We have referred same document for implementation.

    We have used cc2649r2f + one ethernet module connected to uart of R2F which works on TCP IP connection.

    If we are sending boot loader commands through any terminal software it is working properly and it is giving response.

    But we are using TCP/IP connection from server to Ethernet module to send the command.

    Within 127 limit value commands it is working properly. But if values of commands exceeds 128 then command is not receiving properly.

    So what kind of data formatting is needed through server to device?

    waiting for your valuable response.

  • 0 in reply to FI
    Expert 1800 points

    Hi TI Team,

    We are using  TI CC3200 launchpad as wifi connectivity for cc2640r2f launchpad through UART to update custom firmware.

    BLE (R2F) is not responding while sending any boot loader command through CC3200 WiFi module. In this condition we are not keeping any application in R2F. It is replying -ve ack as 00 33 but manually if we send through serial terminal then it is responding properly.

    Please provide your valuable response , how to overcome this problem.

    waiting for your response.

  • 0 in reply to SenseGiz Team
    TI__Mastermind 21210 points

    Hi Rohit,

    Sorry for delay on this. I have requested a colleague to help sort this out.

    regards

  • 0 in reply to FI
    Expert 1800 points

    Thanks FI

  • 0 in reply to SenseGiz Team
    TI__Guru**** 171074 points

    Akash,

    If I understood correctly your description, the bootloader is working fine if connected directly to a serial port, therefore the BLE device itself seems to be responding correctly.

    If that is accurate, the issue seems to be located at the TCP-side of your system, to which the source code of the serial bootloader software provided with the Application Note provided by FI above will be a very critical helper to verify proper communications at a protocol level. It imposes no 7-bit restriction to the exchange of data via serial and therefore should not be a root cause for the issue.

    On the other hand, you could potentially tie a serial protocol analyzer between the two devices to be absolutely sure the data exchanged is valid and stable (an oscilloscope could also be needed in case of signal integrity issues).

    The reason why I am focusing on the HW is simply due to the fact the BLE device is properly responding to the bootloader commands.

    Hope this helps,

    Rafael