-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frame parsing failure #1145
Comments
From a quick look, it seems that the response from the device is corrupt. |
I confirm that this is a known bug in the NCP - I was discussing this with Silabs FAE a few weeks back. |
Thanks for your answer.
Is there a link to follow evolution of the issue?
Le jeu. 24 sept. 2020 à 20:27, Chris Jackson <[email protected]> a
écrit :
… I confirm that this is a known bug in the NCP - I was discussing this with
Silabs FAE a few weeks back.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1145 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACAXKI5LXLJC36UQLIUYJGLSHN6QNANCNFSM4RYEMXHA>
.
|
No - I don't have a link. It was a private discussion with one of the FAEs which came up in a totally unrelated issue - he was just asking if I used the latest firmware and if I'd seen this issue. Maybe there is a discussion on their forum, although I've not seen anything. The impression I got from the discussion is it was not understood -: |
Which stack version are you using? If 6.7.6.0+, are you able to reproduce the issue? |
I use a load of different stacks. I think issue only occurs with 6.8. As you can see in the email above, I was unable to reproduce it with the stack that has the problem. |
I confirm the issue exists with 6.7.6.0 and 6.7.7.0 as well. I'm able to reproduce the issue by simply adding a static block:
Even when you start directly with version 8 instead of 4, you don't get the exception? |
I would suggest that we close this - this doesn't seem to be a problem in the library - the frame returned from the NCP is incorrectly formatted, so there's going to be an error. What do you think? Do you have any suggestion for improving the library response?
Maybe this works around the problem, but it will clearly cause other problems since the system will then not be compatible with some versions of the EZSP. |
Indeed, it is a bug in the NCP code. Closing the ticket. |
We still observe this issue with version 6.7.8.0. |
I'll reopen this - I have seen other reports (or logs) with this error, so I agree it still exists. I have personally never seen it and I'm not sure what is going on. Maybe the change in the NCP format is now the issue - I need to analyses this further. |
Hi,
I just got to this in the logs:
For some reason, the library parses the received frame as an EzspVersionResponse (because the calculated frame ID is 0), therefore the exception thrown inside the constructor.
I'm not sure why yet but this seems to be related to EzspFrame.ezspVersion.
When the library starts, EzspFrame.ezspVersion = EZSP_MIN_VERSION (4). Then, the library sends an EzspVersionRequest (desired protocol version 4) and receives the protocol version from the NCP (8 in my case). Another EzspVersionRequest is sent with desired protocol version 8. EzspFrame.ezspVersion is now changed to 8. If the NCP is restarted (the application stays alive), the error happens.
In order to reprduce the issue easily, you can replace the following:
by:
The text was updated successfully, but these errors were encountered: