CC2530: Unknown SRSP ZDO command (0x65 0x64) received from chip

Hi,

I could not find the 0x64 command either.

Are you using the ZNP example? If yes, what modifications, if any, have you made to it?

You mentioned that you expect AF_INCOMING_MESSAGE, and that the FCS is correct.
Is the payload of the data what you expect (if it were AF_INCOMING_MESSAGE)?

Can you share what other commands, before and after this one, are sent on the serial interface?

Regards,
Toby

Hi Toby,

Thanks for your reply.

I am not sure if we are using the ZNP example, but I do know we enabled source routing and touchlink.

Yes part of the payload is what I expect to be the payload of the AF_INCOMING_MESSAGE. Interesting is that almost the complete ZCL payload (response to command readAttributes['modelId','manufacturerName'] on the basic cluster) is present in the 'malformed' payload, but the last part of the ZCL payload should be 6564656e (according to sniffed network traffic), but it actually is ffffffff. Note that the difference here seems to be identical to the start of the 'malformed' payload fe456564656e0ecf... which gives the payload the unidentified command ids.

The strange thing is that this issue only occurs when reading these specific attributes from this specific end device, if I only read 'modelId' for example I receive the AF_INCOMING_MESSAGE as expected. So it almost seems that the content of the ZCL payload is what triggers some sort of buffer overflow, or similar parsing issue.

Received ZCL payload: 1801010500004216545241444652492072656d6f746520636f6e74726f6c040000420e494b4541206f66205377ffffffff

Expected ZCL payload: 1801010500004216545241444652492072656d6f746520636f6e74726f6c040000420e494b4541206f662053776564656e

Regarding your question on what else is sent on the serial interface:

Start of the read attributes command:

zigbee-clusters:cluster basic read attributes [ 5, 4 ] +0ms
zigbee-clusters:cluster basic send frame ZCLStandardHeader {
frameControl: [],
data: basic.readAttributes { attributes: [ 5, 4 ] },
cmdId: 0,
trxSequenceNumber: 1
} +1ms

First incoming data (AFDataRequestSrcRtg)

zigbee:znp-controller received data fe0164030066 +36ms
zigbee:znp-controller parsed and chunked data {
znpHeader: ZNPHeader {
sof: 254,
length: 1,
cmd: 25603,
data: <Buffer 00>,
fcs: 102
},
data: 'fe0164030066',
dataLength: 6,
buffer: null
} +0ms

Then this comes in, a serial data packet with two messages which then gets chunked (1. AFDataConfirm, 2. unknown)

zigbee:znp-controller received data fe034480000102c4fe456564656e15db1ddb01010078004694010000311801010500004216545241444652492072656d6f746520636f6e74726f6c040000420e494b4541206f66205377ffffffff000000ca +2s
zigbee:znp-controller parsed and chunked data {
znpHeader: ZNPHeader {
sof: 254,
length: 3,
cmd: 17536,
data: <Buffer 00 01 02>,
fcs: 196
},
data: 'fe034480000102c4',
dataLength: 8,
buffer: 'fe456564656e15db1ddb01010078004694010000311801010500004216545241444652492072656d6f746520636f6e74726f6c040000420e494b4541206f66205377ffffffff000000ca'
} +1ms

Here the unknown message is parsed as it was chunked from the serial data packet above

zigbee:znp-controller received data +0ms
zigbee:znp-controller parsed and chunked data {
znpHeader: ZNPHeader {
sof: 254,
length: 69,
cmd: 25956, // unknown command id
data: <Buffer 65 6e 15 db 1d db 01 01 00 78 00 46 94 01 00 00 31 18 01 01 05 00 00 42 16 54 52 41 44 46 52 49 20 72 65 6d 6f 74 65 20 63 6f 6e 74 72 6f 6c 04 00 00 ... 19 more bytes>,
fcs: 202
},
data: 'fe456564656e15db1ddb01010078004694010000311801010500004216545241444652492072656d6f746520636f6e74726f6c040000420e494b4541206f66205377ffffffff000000ca',
dataLength: 74,
buffer: null
} +1ms

I hope the log is understandable this way.

I suspect this is related to Zigbee fragment message. Can you attach your sniffer log and elaborate your issue on the sniffer log?

I have attached a sniffer log (Ubiqua) which shows the network join of the end device as well as the basic read attributes command which response is the malformed packet as described above. Not sure what I could/should elaborate more, please let me know.

7827.zigbee_fragment_issue.cubx.zip

According to your sniffer log, it is not fragmented message. I would suggest you to enable flow control on your ZNP UART interface to see if it can solve this issue.

This issue occurs on a SPI interface, we also have a device with an UART interface with the same CC2530 chip and firmware which does not have this issue. Correct my if I'm wrong, but there is no equivalent to flow control for SPI right?

Yes, there is no flow control on SPI.

Thanks for sharing a detailed explanation.

Which Z-Stack do you have installed (e.g. Z-Stack Home 1.2.2.42930) ?

Robin Bolscher said:

This issue occurs on a SPI interface

I am a bit puzzled here. According to the "Z-Stack ZNP Interface Specification.pdf" (found in <zstack>/Documents/API), using SPI as transport does not have SOF or FCS. You can also see this in MT_TransportSend() (znp_app.c), where npMtUartSend sets SOF and FCS, while npMtSpiSend does not.

Can you send a scopeshot/logic analyser shot of the relevant signals (MRDY, SRDY, MISO, MOSI, CS, [clock]) ?
Another suggestion is to verify the content which the CC2530 sends for the AF_INCOMING_MSG in (e.g. breakpoint in MT_AfIncomingMsg before the CC2530's host initiates the Read Attributes req).