-
-
Notifications
You must be signed in to change notification settings - Fork 629
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
CO_driver init message buffers are only partly initialized #46
Comments
martinwag
added a commit
to martinwag/CANopenNode
that referenced
this issue
Jun 26, 2017
- needs #define CO_NO_LSS_SERVER 1 in CO_OD.h. This will need a change in the OD editor. - no Fastscan support yet - bitrate setting API untested - CANopenNode#46 (driver stuff) - changed some of the other stack files, tried my best to remain compatible with standard non LSS CANopenNode
Closed
iurly
pushed a commit
to iurly/CANopenNode
that referenced
this issue
Nov 27, 2017
Fix for CANopenNode#46 Without this fix, LSS implementation in uninitialized mode (i.e. without NMT) will not work.
martinwag
added a commit
to martinwag/CANopenNode
that referenced
this issue
May 2, 2018
In CO_CANmodule_init() function, rxArray[] is only partly initialized. When not all elements are initialized by the following CANopenNode init functions, undefined behaviour occurs upon message reception. This causes a problem for me on implementing LSS. In normal operation all elements are initialized correctly. But with LSS, there is a case where only LSS is initialized and the rest of the stack is not (Startup without valid node ID). See CANopenNode#46
merged in 8b01062 |
martinwag
added a commit
to martinwag/CANopenNode
that referenced
this issue
Jan 22, 2024
In CO_CANmodule_init() function, rxArray[] is only partly initialized. When not all elements are initialized by the following CANopenNode init functions, undefined behaviour occurs upon message reception. This causes a problem for me on implementing LSS. In normal operation all elements are initialized correctly. But with LSS, there is a case where only LSS is initialized and the rest of the stack is not (Startup without valid node ID). See CANopenNode#46
martinwag
added a commit
to martinwag/CANopenNode
that referenced
this issue
Jan 22, 2024
In CO_CANmodule_init() function, rxArray[] is only partly initialized. When not all elements are initialized by the following CANopenNode init functions, undefined behaviour occurs upon message reception. This causes a problem for me on implementing LSS. In normal operation all elements are initialized correctly. But with LSS, there is a case where only LSS is initialized and the rest of the stack is not (Startup without valid node ID). See CANopenNode#46
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In CO_CANmodule_init() function, rxArray[] is only partly initialized. When not all elements are initialized by the following CANopenNode init functions, undefined behaviour occurs upon message reception.
This causes a problem for me on implementing LSS. In normal operation all elements are initialized correctly. But with LSS, there is a case where only LSS is initialized and the rest of the stack is not (Startup without valid node ID).
I've solved this by defaulting all values of the array as followed:
Mask must be set to not mask out any bits as otherwise software filter in
if(((rcvMsgIdent ^ buffer->ident) & buffer->mask) == 0U){
will always match when buffer is not set up by stack.
For me this works as expected, but I don't know if we can just apply that to all the other avaliable drivers. There shouldn't be a problem as those values currently contain "random" values, but who knows...
txArray[] is also only partially initialzied. However, I think this is not a problem because those entries are only used after initialization.
The text was updated successfully, but these errors were encountered: