CC2652 freezes with UART firmware

[Morteza-24]

Hi and thanks for this awesome firmware.

I'm using this firmware on a CC2652 connected to an STM32 for UART data transmission. Initially, everything works flawlessly. However, after some time and after sending and receiving a bunch of messages, the CC2652 freezes and stops working. Even the LED stops blinking every 5 seconds, indicating the processor has completely freezed.

For now I have set up the watch dog timer and the CC2652 is reset each time it freezes. But this is happening quite a lot, like every minute of continuous message exchange.

I have tried so hard to identify a pattern or pinpoint the specific action that triggers this issue but I've been unable to do that. I've tried putting a delay before sending data to CC2652, tried sending data in short intervals, long intervals, tried changing the baud rate, the stop bit etc. but no luck.

I have two different modules for CC2652, RF-BM-2652P2 and RF-BM-2652P4. And both of them have this same behavior.

I would greatly appreciate your assistance in resolving this matter. If you require any additional information, please feel free to let me know.

Thank you so much for your time and support.

an example of the firmware configuration I'm using; the version I'm using is also visible in the picture

[Morteza-24]

UPDATE: I also tried this with the newest version of the firmware and it has the same behavior.

[ptvoinfo]

Please attach your data example that I can use for tests.

[Morteza-24]

I have included an image of my Zigbee2MQTT log in which you can see some of the data being sent to and received from the CC2652.

The whole purpose of this setup is to communicate with the STM32 MCU to control 16 different switches connected to it. So the data that is being transmitted, basically consists of some numbers to select some of these switches, and some special characters/bytes to specify operations (e.g. on, off, etc.).

So there's nothing more than what you see in this image that causes the CC2652 to freeze. Sometimes it happens after 1 minute of sending these messages, sometimes after 2 minutes, and so forth.

Also the code that I'm using on the STM32 for UART communication is similar to this example.

And I also wanted to mention that I'm using RTIC on the STM32, I don't know if that's relevant or not.

[ptvoinfo]

@Morteza-24 Sorry, but it is a log from Z2M, but I need a raw data example that you send to an UART port.

[Morteza-24]

Sorry about the confusion.

Here is the data that I'm sending to the CC2652 from the STM32:

It's from the debugger of the STM32. I'm printing every message that is being sent to the CC2652.

BTW, I have tested the Rx and Tx of CC2652 separately, and what I have found is that when I'm only using Tx it doesn't freeze, but when I use the Rx of the CC2652 it freezes (i.e. it only freezes when the STM32 is sending messages to CC2652)

[Morteza-24]

Here is the full diagram of my setup:

Here is the data that I send from the coordinator to the CC2652 (1):

Here is the data that I send from the STM32 to the CC2652 (2): This data is exactly what I have received from the CC2652 on the STM32. Basically what the STM32 is doing is it echoes back whatever it receives on uart.

Here is the data that I receive on the coordinator from the CC2652 (1):

[Morteza-24]

Hi @ptvoinfo,

Thank you for the new update.

Since version 1.9.0.22, the issue with CC2652 freezing has been resolved. However, three new issues have arisen:

1. The first byte of the UART message is not sent to the coordinator. For instance, when I send [70, 82, 11, ...] to the CC2652 via UART, what reaches the coordinator is [82, 11, ...].
2. An additional byte with a value of 0 is appended at the end of every message. For example, if I send [..., 82, 11, 13] to the CC2652 via UART, what arrives at the coordinator is [..., 82, 11, 0]. (In this example, 13 (0x0D) is configured as the "packet end" in the firmware.)
3. Some messages originating from the coordinator are lost and not forwarded through the CC2652's UART.

Could you please investigate these issues?

Thank you.

[Morteza-24]

Also, I see the following error in Z2M logs when CC2652 joins the network:

[Morteza-24]

3. Some messages originating from the coordinator are lost and not forwarded through the CC2652's UART.

I suspect this third problem relates to "packet end". I use 0x0D as packet end. I tried putting two 0x0Ds at the end of my messages and this problem happened less often. And then I tried adding three 0x0Ds at the end of my messages and no messages have been lost so far. It seems like the problem is resolved by putting three packet ends at the end of every message.

[ptvoinfo]

1,2 - please try the latest version: https://ptvo.info/download/ptvo-firmware-2024-07-23.zip 3 - the device has a limited memory and slow data transmission channel. If your data stream is fast, the firmware can miss some data packets. Also, the internal buffer for UART data is 128 bytes. If your data strings are longer, they will be truncated.

[Morteza-24]

Thank you so much.