-
Notifications
You must be signed in to change notification settings - Fork 4
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
Cycle CS pin in case of checksum error #4
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this PR!
Please rebase your PR on master for running the QA pipeline. The previous configuration did not cover PRs, which is fixed now.
@@ -942,6 +942,7 @@ where | |||
|
|||
let pec = PEC15::calc(&result[0..6]); | |||
if pec[0] != result[6] || pec[1] != result[7] { | |||
self.cs.set_high().map_err(Error::CSPinError)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my point of view, it's the correct & expected behavior for setting the CS pine state here.
As the only upper method calling read()
is within read_daisy_chain()
, which is managing the CS pin state (except the case you just found).
@@ -973,13 +974,13 @@ where | |||
} | |||
|
|||
// Constant of 276 °C, which needs to be subtracted | |||
const TEMP_SUB: i16 = 20976; | |||
const TEMP_SUB: i32 = 20976; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
Please try to add a unit test.
With this PR, I’m adding a line which disables the CS pin in case of a checksum error.
Sometimes it happens that a slave gets in a state which never exits a loop of checksum errors, and a chip select cycle is needed.
With this fix, my firmware never gets stuck in that kind of loop. I don’t know whether this solution applies universally, so I’d like to have my change reviewed, as I am still relatively new to this BMS chip (LTC6813).
I also don’t know if state changes of the CS pin should happen in this function, as callers might not expect this.