Feedback on EmberZNet 8.1.0

[Nerivec]

Continuing on #13 with the new version.

• A big one... it appears software flow control (xon/xoff) is broken, a default Simplicity Studio zigbee_ncp project (with only pin config), does not work at all. The same process in 8.0.2 works.
• [8.x.x] Similarly to remaining issue in previous post, it seems, whatever the firmware actually has for RAW_TRANSMIT_COMPLETE_HANDLER, it does not match this signature:

  • simplicity_sdk/protocol/zigbee/app/ncp/meta-inf/ezsp.yaml

    Lines 9787 to 9812 in 8627f84

    	## RAW_TRANSMIT_COMPLETE_HANDLER
    	{
    	value: "0x0098",
    	needGeneratedHandler : "no",
    	commandName: "rawTransmitCompleteHandler",
    	description: "A callback invoked by the EmberZNet stack when the
    	MAC has finished transmitting a raw message.",
    	responseArguments: [
    	{
    	type: "uint8_t",
    	name: "messageLength",
    	description: "Length of the message that was transmitted.",
    	},
    	{
    	type: "uint8_t[messageLength]",
    	name: "messageContents",
    	description: "The message that was transmitted.",
    	},
    	{
    	type: "sl_status_t",
    	name: "status",
    	description: "SL_STATUS_OK if the transmission was successful,
    	or SL_STATUS_ZIGBEE_DELIVERY_FAILED if not",
    	},
    	],
    	},

• We discovered an issue with SEND_RAW_MESSAGE that apparently has been around for a while (7.1.1 appears to be working as expected, but a more thorough search is in order); all cases including the zigbee_zll component on the NCP. When using this mechanism to send a Touchlink InterPAN message, MAC_FILTER_MATCH_MESSAGE_HANDLER no longer gets triggered, even though the response frame can be seen via mfglib RX through a concurrently running NCP. This is using default firmware configuration, no modification to mac filters/table. I can't seem to find any difference on that point in the SDKs, so I assume the problem is in the closed source... or does something now needs more configuring for this to work properly?
  • Note: sniffed MAC frames were compared via Wireshark and confirmed identical for both request and response in 7.1.1 and 8.0.2, excluding malformed or differing frames as the source of the issue.
• [7.4.x-8.x.x] UART buffering appears to have changed in a way that makes the NCP very unstable under load (like an ongoing OTA on the network), it will throw a lot of max ACK timeout count errors. A "mostly-working" workaround appears to be increasing the default SL_IOSTREAM_USART_VCOM_RX_BUFFER_SIZE from 32 to 128 or above. This affects mostly software flow control (so, unclear on 8.1.0 because of first point), and appears pre-dominantly on CP210x-driven modules.

Note: Will keep this updated if new issues are discovered or more information can be provided.