-
Notifications
You must be signed in to change notification settings - Fork 0
add watchdog timer for mspm0 i2c driver #45
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
Conversation
Emil-Juhl
left a comment
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.
When the system is crashing, the I2C lines (SDA/SCL) are not being
reset and might stay LOW.
I don't believe this claim to be correct. The i2c lines are released just fine by the mspm0 reset handler. Otherwise I believe you could face the same issue with a deliberate panic, no?
I think what you wanted to write was something about certain i2c controllers, such as the a2b chip, ad2428 (I think), can impose limitations for clock stretching duration - and this limitation can be enforced by the watchdog to prevent triggering erroneous behavior in the i2c controller (ad2428) itself.
tldr; the lines are not released |
f609605 to
183b970
Compare
tbursztyka
left a comment
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.
lgtm
add properties to configure the I2C watchdog reset timeout and and panic error code. Also, add a new kconfig property to define the driver init priority. Since the i2c driver has a dependency to the counter driver, we need to adjust for that. Signed-off-by: Dimitris Karnikis <dika@bang-olufsen.dk>
describe the watchdog timer property that will reset the mcu and the i2c lines (to high) to avoid potential SCL stuck low issues Signed-off-by: Dimitris Karnikis <dika@bang-olufsen.dk>
When the system is crashing, the I2C lines (SDA/SCL) are not being
reset and might stay LOW. To address this issue, we need to ensure that
none of the user i2c driver callbacks (that are doing reads or writes)
are taking longer than CONFIG_I2C_MSPM0_WATCHDOG_TIMEOUT. So we
fire a timer before each call. If the callback doesn't finish fast
enough, the watchdog callback will reset the i2c lines, NACK the i2c
message and panic with the CONFIG_MSPM0_I2C_WATCHDOG_PANIC_CODE
error code.
The timeout is configured with CONFIG_I2C_MSPM0_WATCHDOG_TIMEOUT
The panic error code is configured with
CONFIG_MSPM0_I2C_WATCHDOG_PANIC_CODE.
To make use of this reboot feature, the device tree needs to provide
a reference to a hardware timer. Let's say we want to use timer timg7
as a watchdog:
We need to configure that timer in the dts:
```
&timg7 {
status = "okay";
mode = <ONE_SHOT_DOWN>;
prescaler = <0>;
divide-ratio = <RATE_1>;
};
```
and then reference in the i2c block:
```
&i2c0 {
watchdog-timer = <&timg7>;
extras ...
```
Since we are invoking a software panic on the mcu, make sure to disable
the COREDUMP since the default backend is the "logging" one and it takes
too much of the cpu resources, thus delaying the mcu reboot.
This can be done with:
```
CONFIG_DEBUG_COREDUMP=n
```
Of course for now, the implementation is using a counter timer since
we don't have a mspm0 watchdog.
We need to also use I2C_MSPM0_INIT_PRIORITY as the driver init
priority.
Signed-off-by: Dimitris Karnikis <dika@bang-olufsen.dk>
183b970 to
fdb4e6a
Compare

Check commits.