zigpy / zigpy-znp

TI CC2531, CC13x2, CC26x2 radio support for Zigpy and ZHA
GNU General Public License v3.0
149 stars 40 forks source link

Failed OSALNVReadExt request #243

Closed wang70880 closed 8 months ago

wang70880 commented 8 months ago

I am using zigpy-znp to control my cc2538 with Z-Stack 3.0.2.

When I run the load_network_info() function, which first requests to read the NIB attributed in the NVRAM, the request failed with no responses. The logs are as follows.

[zigpy_znp.api] 2024-03-16 00:38:07 DEBUG: Detected Z-Stack 3.0 [zigpy_znp.api] 2024-03-16 00:38:07 DEBUG: Connected to COM4 [zigpy_znp.api] 2024-03-16 00:38:07 DEBUG: Sending request: SYS.OSALNVLength.Req(Id=<OsalNvIds.NIB: 33>) [zigpy_znp.uart] 2024-03-16 00:38:07 INFO: <-- Received data: b'\xFE\x02\x61\x13\x74\x00\x04' [zigpy_znp.uart] 2024-03-16 00:38:07 INFO: Parsed frame: TransportFrame(payload=GeneralFrame(header=CommandHeader(id=0x13, subsystem=Subsystem.SYS, type=CommandType.SRSP), data=b'\x74\x00')) [zigpy_znp.api] 2024-03-16 00:38:07 DEBUG: Received command: SYS.OSALNVLength.Rsp(ItemLen=116) [zigpy_znp.api] 2024-03-16 00:38:07 DEBUG: Sending request: SYS.OSALNVReadExt.Req(Id=<OsalNvIds.NIB: 33>, Offset=0)

The error message is as follows.

File "C:\Users\Administrator\Downloads\zigpy-znp-dev\zigpy-znp-dev\zigpy_znp\api.py", line 105, in _load_network_info nib = await self.nvram.osal_read(OsalNvIds.NIB, item_type=t.NIB)

File "C:\Users\Administrator\Downloads\zigpy-znp-dev\zigpy-znp-dev\zigpy_znp\nvram.py", line 177, in osal_read read_rsp = await self.znp.request(

File "C:\Users\Administrator\Downloads\zigpy-znp-dev\zigpy-znp-dev\zigpy_znp\api.py", line 1056, in request async with async_timeout.timeout(

File "C:\ProgramData\anaconda3\Lib\site-packages\async_timeout\__init__.py", line 129, in __aexit__ self._do_exit(exc_type)

File "C:\ProgramData\anaconda3\Lib\site-packages\async_timeout\__init__.py", line 212, in _do_exit raise asyncio.TimeoutError

TimeoutError

I further dive into the request implementation in sys.py, and find that the command ID seems inconsistent with the Z-Stack monitor and test documentation. Specifically, the code is as follows. OSALNVReadExt = t.CommandDef( t.CommandType.SREQ, 0x1C, req_schema=( t.Param("Id", t.uint16_t, "The Id of the NV item"), t.Param( "Offset", t.uint16_t, "Number of bytes offset from the beginning of the NV value", ), ), rsp_schema=( t.Param("Status", t.Status, "Status is either Success (0) or Failure (1)"), t.Param("Value", t.ShortBytes, "The value of the NV item"), ), )

However, the monitor and test documentation shows that the command ID should be 0x08 (instead of 0x1C in the code). I am not sure if I have misunderstandings about the code, or the code follows another version of the documentation, or the implementation is wrong.

I would like to know if this is the reason why the request failed with no reply, and if the implementation of the OSALNVReadExt is correct. Thanks.

puddly commented 8 months ago

Unknown commands should still receive a response so it sounds like something is crashing. Can you try performing a chip erase and reflash the firmware? The older CC chips suffer from NVRAM corruption issues.

wang70880 commented 8 months ago

Unknown commands should still receive a response so it sounds like something is crashing. Can you try performing a chip erase and reflash the firmware? The older CC chips suffer from NVRAM corruption issues.

Thanks for your rapid reply!

OK, let me debug the Z-stack. In fact I did not use the provided firmware but the official ZNP sample application. Let me check if anything is crashing in it.

By the way, is there any provided firmware for CC2538?

wang70880 commented 8 months ago

I have solved the issue. The root cause is the uart RX and TX buffer size is small while the NIB info has too many bytes.