• State Resolved
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 154 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

CC1352P7: Wi-SUN RCP

CC1352P7: rcp_lmac on linux host

AliGeda
Prodigy 70 points
Part Number: CC1352P7
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG,

Hi,

This is related to my last ticket that I managed to get my docker and linux side working.

I have LP-CC1352P-1 using the oroginal rcp_lmac example and the RCP doe snot get anything from the br. please refer to my screenshot where the system is keep sending and waiting for a response. I was told the default baud for that is already 460800.

I have no nodes programmed by now, not sure if that matters, as I was expecting to get something from rcp_lmac first. Is there any command/charecters that I can send via other uart just to test it.

image.png

I even wrote this to send a dummy response but still nothing.
image.png

Thanks,

AliGeda

 

  • 0
    TI__Intellectual 2957 points

    Hi AliGeda,

    From the screenshot you had shared before in your other post, it seemed to be working as you received "RCP init CNF received".

    Could you try the following.

    1. Make sure the device is still connected on /dev/ttyAMA0 (before you had it connected on /dev/ttyACM0)

    2. Long press the power button to reboot the device.

    3. Use UniFlash to erase the entire flash, flash it again.

    4. Remove nv-simulation.bin

    Best regards,

    Daniel

  • 0
    Prodigy 70 points

    Thanks Daniel,

    I was using the USB connector from the dev board but every time I rebooted the host it was assigning different number ACM0/1/2 so I went to use the Pins12/13 on the dev board (UART0) instead and hence gives /dev/ttyAMA0.

    I have not changed the firmware since but I will delete the nv-simulation.bin as suggested later and let you know.

    Thanks mate,

    AliGeda

  • 0 in reply to AliGeda
    TI__Intellectual 2957 points

    Sure,

    Let me know how it goes!

    Best regards,

    Daniel

  • 0 in reply to AliGeda
    Prodigy 70 points

    Hi Daniel,

    • RCP firmware is running correctly and transmits continuous binary frames at 460800 (verified by connecting CC1352 TX directly to a PC).
    • Pi UART2 loopback test at 460800 passes, confirming correct host TX/RX timing.
    • When Pi TX is connected to CC1352 RX (DIO12), the RCP changes behaviour (TX activity gated), but never completes Spinel handshake (no IND_RESET). Even the CC sends something at each request captured by PC
    • Border Router transitions from timeout to hang while attempting to decode RX data, indicating RX activity is present but frames are invalid.
    • This behaviour persists even with correct baud on both sides and no NV restore.

    This strongly suggests an RX integrity or pin-mapping issue specific to LP-CC1352P7-1 at 460800, rather than baud or protocol mismatch.

    Questions:

    1. On LP-CC1352P7-1, are DIO12 (RX) / DIO13 (TX) officially supported for RCP UART at 460800, or are these pins expected to remain tied to XDS110 circuitry even when externally powered?

    2. Is it recommended or required to remap the RCP UART pins (e.g., away from DIO12/13) when using an external host instead of XDS110?

    3. Can you confirm where in the SDK the RCP UART RX/TX pins are defined for the LP-CC1352P7-1 platform (board.c / platform file), and whether they are safe to modify?

    4. Are there any documented signal-integrity limitations or errata for RCP UART RX at 460800 on the LaunchPad (e.g., loading from debugger path, series resistors, etc.)?

    5. Do you have a reference design or known-good pin mapping for CC13xx RCP UART when connected to a Linux host (Pi, NXP, etc.) at 460800?

    6. What is the hex value of the IND_RESET so I can simulate it and see what the issue is

    My goal is to move this design to a custom PCB, so understanding whether this is a LaunchPad-specific limitation vs a general RCP constraint is important.

    Thanks again,

    AliGeda

  • +1 in reply to AliGeda
    TI__Intellectual 2957 points

    Hi AliGeda,

    1. Yes 460800 is supported. When not using the XDS110 you should remove the UART jumpers from the LaunchPad. Remember to also connect GND with to Raspberry PI.

    2. You don't need to remap it if you remove the jumpers to the XDS110.

    3. The UART TX/RX are set in SysConfig. By default they use the "Display" driver. If you want to change the pins, you need to change the "Use Hardware" to none. Then you will be able to select a different pin.

    4. No

    5. We don't. You can check how the BeaglePlay integrates the CC1352P7 GitHub - beagleboard/beagleplay: Mirror of https://openbeagle.org/beagleplay/beagleplay

    6. Sorry, what is the IND_RESET you are referring to?

    Best regards,

    Daniel

  • 0 in reply to Daniel Guarecuco Aguiar
    Prodigy 70 points

    Pi 5 is away different to Pi 4. I ended up using ttyAMA2 and editing the yml file to see all the logs.

    Thanks.