• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 515 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.

CC2652P7: RF-BM-2652P4 CC2652P7 - Thread Firmware

Dustin Utecht
Prodigy 10 points
Part Number: CC2652P7
Other Parts Discussed in Thread: SYSCONFIG, CC1352P7, CC2652R7

Tool/software:

Hello,

i tried to build and use the ot-ti (https://github.com/TexasInstruments/ot-ti) Firmware for an RF-BM-2652P4 CC2652P7.
I cloned the repository, installed the toolchain and build the firmware, which worked fine. But somehow it don't worked with the home assistant open thread border router addon.
The logs always shows:

54d.18:03:39.963 [W] P-SpinelDrive-: Wait for response timeout
54d.18:03:41.965 [W] P-SpinelDrive-: Wait for response timeout
54d.18:03:43.968 [W] P-SpinelDrive-: Wait for response timeout

So i thought maybe i have the same tx/rx pins. So i opened the project in sysconfig (i followed the documentation and used the @cliArgs line) and edited in the software on the uart2 page the tx/rx pins in the PinMux panel.
But i still don't get it to work.

What are the default pins and bauds ?
I need TX on DIO12 and RX on DIO13.

I used an FOCA FT232 USB to which is connected to the CC and to via USB on the pi.

Does anybody have an idea whats wrong or how i can check/debug that ?
I also tried to connect to the CC via terminal, as the documentation/readme said there are some commands, but none of them worked.

best regards
codmdu
  • 0
    TI__Guru**** 218477 points

    Hello codmdu,

    For the CC2652P7 target you should be using the LP_CC1352P7_4 build parameter (i.e. binary compatible result).  Keep in mind that MCU TX <--> Host RX and vice versa.  Thus the default UART pins are DIO12 for MCU RX and DIO12 for MCU TX (115200 baud by default).  If you truly need to flip these pins, then please follow the Sysconfig directions to correctly open the SysConofig file and make changes to the UART module.

    I am familiar with using ot-br-posix as the host (Linux machince, RPi, or BBB) for SimpleLink MCU RCPs.  There is a SimpleLink Academy Lab for setting up a RCP host environment, where the /etc/default/otbr-agent file can be changed to accommodate different baud rates or USB port names.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 10 points

    Thank you for the Info, we also found it out in the meanwhile because of the fork of koenkk (https://github.com/Koenkk/OpenThread-TexasInstruments-firmware/blob/main/docs/adapters.md).
    Why is that the case ? Why we need LP_CC1352P7_4 instead of LP_CC2652R7 for the CC2652P7 ?
    I would love to understand that.

    But we still have an issue, we tried to flash that firmware using the https://github.com/xyzroe/XZG Frontend but it fails, because the used esp has not enough space left on the device. That the cause because the build thread firmware has a size of 2,7MB.
    So we tried the Firmware of koenkk which has ~600KB after converting the .hex to .bin using (https://github.com/algodesigner/hex2bin).
    (We also tried to flash the .hex directly but it we don't get it working)
    We was able to flash it through the XZG Frontend using the .bin, but the Frontend shows no Firmware version.

    If we use the original compiled 2,7MB Firmware and flash it using an j-link (jtag) directly to the CC we get the same result => no firmware version shown.
    Also we don't understand why the compiled version has 2,7MB but the firmware from koenkk has 227KB/600KB.
    We also found other firmware which are all under 400KB e.g. UZG, tube_gateways, smlight etc.

    The compiled firmware has also an .out extension.
    Some of the found firmware uses .hex and some .bin, what is correct ?
    And what is the recommended way to flash the firmware to the CC's ?

    Regard
    codmdu

  • 0 in reply to Dustin Utecht
    TI__Guru**** 218477 points
    Dustin Utecht said:
    Why we need LP_CC1352P7_4 instead of LP_CC2652R7 for the CC2652P7 ?

    Although the number is closer between the CC2652R7 and CC2652P7, the CC2652P7 is pin and binary compatible with the CC1352P7.  This is due to the additional radio outputs for both the High PA and normal 2.4 GHz paths.

    Dustin Utecht said:
    The compiled firmware has also an .out extension.
    Some of the found firmware uses .hex and some .bin, what is correct ?
    And what is the recommended way to flash the firmware to the CC's ?

    The .out executable file contains symbols necessary to debug the project using Code Composer Studio.  As this is not necessary for firmware loading, output hex and binary files are capable of being generated using tools.  Binary files will be larger as it does not allow for holes and the CCFG resides at the end of flash memory.  Here is a post-build step from a CCS project for generating a hex image:

    ${CG_TOOL_ROOT}/bin/tiarmobjcopy ${BuildArtifactFileName} --output-target ihex ${BuildArtifactFileBaseName}.hex

    And a similar option for binary file generation:

    ${CG_TOOL_ROOT}/bin/tiarmobjcopy ${BuildArtifactFileName} --output-target binary  ${BuildArtifactFileBaseName}.bin

    Here is an explanation of the tiarmobjcopy tool from the TI Arm Clang Compiler Tools User’s Guide.  You should be able to use the tool outside of CCS with a command prompt when using the correct arguments.

    Dustin Utecht said:
    We was able to flash it through the XZG Frontend using the .bin, but the Frontend shows no Firmware version.

    If we use the original compiled 2,7MB Firmware and flash it using an j-link (jtag) directly to the CC we get the same result => no firmware version shown.

    I'm not sure what "no firmware version" implies for the XZG frontend, as this would be dependent on whatever response it expects to receive from the CC2652P7 RCP.

    Regards,
    Ryan