• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 226 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2652P: Cannot change baudrate, flowControl (or rather, the settings have no effect)

Olliver Schinagl
Prodigy 50 points
Part Number: CC2652P
Other Parts Discussed in Thread: CC1352P, Z-STACK

Tool/software:

Hi,

So I want to enable hardware flowControl on my sonoff Zigbee stick, which has those wires routed (via a switch). I figured, should be easy, right? I removed/disabled the XGS110 from the znp example, and replaced it with a normal UART2. Sadly however, enabling flow control didn't result in actually functional flow control. Everything worked as before. So then I figured, lets change the baudrate, that should work? But alas, communications where still on 115200. Was my UART being used at all? Swapping the pins around (TX -> CTS, RX -> RTS) for sure resulted in non-functional communications. So the pad setup works, the mux settings work, just not the flow control or baud rate changes.

Here's my diff compared to the regular znp.syscfg

```diff

diff -u --color znp.syscfg ../../coordinator/Z-Stack_3.x.0/znp_CC1352P_2_LAUNCHXL.syscfg 2024-08-17 22:11:36 [0]
--- znp.syscfg 2024-08-17 22:10:34.160240772 +0200
+++ ../../coordinator/Z-Stack_3.x.0/znp_CC1352P_2_LAUNCHXL.syscfg 2024-08-17 21:35:53.842245876 +0200
@@ -11,7 +11,7 @@
*/
const CCFG = scripting.addModule("/ti/devices/CCFG");
const rfdesign = scripting.addModule("/ti/devices/radioconfig/rfdesign");
-const Display = scripting.addModule("/ti/display/Display", {}, false);
+const Display = scripting.addModule("/ti/display/Display");
const Display1 = Display.addInstance();
const AESCBC = scripting.addModule("/ti/drivers/AESCBC");
const AESCBC1 = AESCBC.addInstance();
@@ -73,17 +73,12 @@

rfdesign.rfDesign = "LAUNCHXL-CC1352P-2";

-Display1.$name = "CONFIG_DISPLAY";
-Display1.baudRate = 57600;
-Display1.uart.$name = "CONFIG_DISPLAY_UART";
-Display1.uart.flowControl = true;
-Display1.uart.uart.$assign = "UART0";
-Display1.uart.uart.txPin.$assign = "boosterpack.4";
-Display1.uart.uart.rxPin.$assign = "boosterpack.3";
-Display1.uart.uart.ctsPin.$assign = "boosterpack.19";
-Display1.uart.uart.rtsPin.$assign = "boosterpack.36";
-scripting.suppress("Connected to hardware,@@@.+?@@@ is connected to XDS110 UART on the CC1352P-2 LaunchPad\\. Consider selecting it in \'use hardware\' above\\. @@@.+?@@@", Display1.uart.uart, "txPin");
-scripting.suppress("Connected to hardware,@@@.+?@@@ is connected to XDS110 UART on the CC1352P-2 LaunchPad\\. Consider selecting it in \'use hardware\' above\\. @@@.+?@@@", Display1.uart.uart, "rxPin");
+Display1.$hardware = system.deviceData.board.components.XDS110UART;
+Display1.$name = "CONFIG_DISPLAY";
+Display1.uart.$name = "CONFIG_DISPLAY_UART";
+Display1.uart.uart.$assign = "UART0";
+Display1.uart.uart.txPin.$assign = "boosterpack.4";
+Display1.uart.uart.rxPin.$assign = "boosterpack.3";

AESCBC1.$name = "CONFIG_AESCBC_0";

```

Not sure what that first change is about, but the UART config looks correct right? Here's my full znp.sysfg `github.com/.../znp_CC1352P_2_hwfc.syscfg`

If I look at `ti_drivers_config.c` I also see the important bits configured.

```C

const DisplayUart2_HWAttrs displayUart2HWAttrs = {
.uartIdx = CONFIG_DISPLAY_UART,
.baudRate = 57600,
.mutexTimeout = (unsigned int)(-1),
.strBuf = displayUART2Buffer,
.strBufLen = Display_UART2BUFFERSIZE
};

...


static const UART2CC26X2_HWAttrs uart2CC26X2HWAttrs[CONFIG_UART2_COUNT] = {
{
.baseAddr = UART0_BASE,
.intNum = INT_UART0_COMB,
.intPriority = (~0),
.rxPin = CONFIG_GPIO_DISPLAY_UART_RX,
.txPin = CONFIG_GPIO_DISPLAY_UART_TX,
.ctsPin = CONFIG_GPIO_DISPLAY_UART_CTS,
.rtsPin = CONFIG_GPIO_DISPLAY_UART_RTS,
.flowControl = UART2_FLOWCTRL_HARDWARE,
.powerId = PowerCC26XX_PERIPH_UART0,
.rxBufPtr = uart2RxRingBuffer0,
.rxBufSize = sizeof(uart2RxRingBuffer0),
.txBufPtr = uart2TxRingBuffer0,
.txBufSize = sizeof(uart2TxRingBuffer0),
.txPinMux = IOC_PORT_MCU_UART0_TX,
.rxPinMux = IOC_PORT_MCU_UART0_RX,
.ctsPinMux = IOC_PORT_MCU_UART0_CTS,
.rtsPinMux = IOC_PORT_MCU_UART0_RTS,
.dmaTxTableEntryPri = &dmaUart0TxControlTableEntry,
.dmaRxTableEntryPri = &dmaUart0RxControlTableEntry,
.rxChannelMask = 1 << UDMA_CHAN_UART0_RX,
.txChannelMask = 1 << UDMA_CHAN_UART0_TX,
.txIntFifoThr = UART2CC26X2_FIFO_THRESHOLD_1_8,
.rxIntFifoThr = UART2CC26X2_FIFO_THRESHOLD_4_8
},
};

```

Can't see how UART2 is related to the Display, other then the name; but since the baudrate is part of the display, and the pinmux is part of the UART, I'm happy to assume this just works (tm). Also investigating the code, there's nothing obvious where things are not passed into the uart2 driver(s).

I've setup (rm -rf workspace, import, configure, build) things a whole bunch of times, so it's not a matter of uncleaned objects sadly.

  • 0
    TI__Mastermind 32830 points

    Hi

    For ZNP, I believe the baudrate for its serial interface is set to a value defined in itself, rather than the syscfg file.

    Taking a quick look, it seems to be set in "NPITLUART_initializeTransport" (npi_tl_uart.c), where NPI_UART_BR is defined in npi_tl_uart.h.

    Can you try setting the UART settings there? (Might be easiest to first confirm that you can change the baudrate in that file first).

    Thanks,
    Toby

  • 0 in reply to Toby
    Prodigy 50 points

    Changing the baudrate was actually a way for me to see if I could change the duplexing. I was mostly going down that rabbit hole too, but let me check that file. I did hardcode it in `source/ti/drivers/UART2.c` but to no avail. I'll try your suggestion in a few days! Thanks for that tip and I'll get back to you.

  • 0 in reply to Olliver Schinagl
    Prodigy 50 points

    So I've been reading a little bit into NPI, which stands for Network Processor Interconnect, e.g. the link between the actual radio chip and the Application processor. Assuming that the radio chip is the CC1352 (wasn't that an M0?) and the application processor something like CC2652 (wasn't that an M4?) (I'm sure that's not quite right in numbers, but the gist of it should be), then this would about the speed between those two components. Surprised if this where UART internally, but the fact that these configuration options exists, indicates  that internally these two speak an internal protocol that is uart, and your finding would mean that internally they speak at 115200 baud. So even if I found the right knob to up the baudrate to, say 3Mbaud, the application processor and wireless processor would still be communicating at 115200 baud. Some benefit could surely be had, quite less then I'd hope to achieve. Unless of course the internal protocol can be increased as well. Which is why I'd be supprised that internally they'd use something 'ugly' as UART, instead of something nicer such as SPI. I think the CC1101-ish chips did SPI didn't they?

    The chip does support both methods however, which is what `# error "NPI ERROR: NPI_USE_UART or NPI_USE_SPI must be defined."` tells us.

    Compiler output does say `-DNPI -DNPI_USE_UART` however, which comes from the projectspec file. Sadly no projectspec sets `NPI_USE_SPI` so I wonder if it's as simple as flipping the chip and everything works.

  • 0 in reply to Olliver Schinagl
    TI__Mastermind 32830 points

    Yes, you are correct that there are two cores within CC2652, the main application core (M4F) and radio core (M0). The interface between these two are not configurable by the user, but should be sufficient to support protocols like Zigbee and Bluetooth LE.

    The NPI serial interface refers to the interface between CC2652 and an external controller. This is configurable, including baudrate.

    Currently only UART is supported for ZNP NPI.

  • 0 in reply to Toby
    Prodigy 50 points

    Right,  so the application core is called Network Processor Interconnect in simplelink; not confusing at all :)

    I'll let you know if I get this to work!

  • 0 in reply to Olliver Schinagl
    Prodigy 50 points

    So this does indeed work. This make me go seriously wtf however.

    We configure everything in syscfg, it generates the files. The pin/pad config IS honored through these settings, but the baudrate (and probably duplex config) is not?! What's going on ...