[jira] [Commented] (MYNEWT-865) hal i2c lockup on nrf platform if timeout is too short
[ https://issues.apache.org/jira/browse/MYNEWT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260144#comment-16260144 ] Simon Ratner commented on MYNEWT-865: - [~marko] Is a similar change needed for TXD on the write side? > hal i2c lockup on nrf platform if timeout is too short > -- > > Key: MYNEWT-865 > URL: https://issues.apache.org/jira/browse/MYNEWT-865 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: HAL >Affects Versions: v1_2_0_rel >Reporter: William San Filippo >Assignee: Marko Kiiskila > Fix For: v1_3_0_rel > > > The nordic TWI (i2c) interface locked up when a too short timeout was > applied. Not sure of all the details here but I believe another transaction > was started and that this transaction caused the TWI interface to become > unresponsive. > The basic issue here is that the timeout is in os ticks and it is possible, > given the current code implementation, that there is basically no timeout > applied as a timeout of 1 os tick will give you a timeout of 0 to 1 os tick > (in msecs). > Another issue is that the code does not attempt to calculate whether the > timeout is too short given the length of i2c data to be sent, the clock > frequency and the time per os tick. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-865) hal i2c lockup on nrf platform if timeout is too short
[
https://issues.apache.org/jira/browse/MYNEWT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16260125#comment-16260125
]
Simon Ratner commented on MYNEWT-865:
-
[~marko] Agree that fine grained timeout is probably not necessary, as long as
it is always non-zero. And i see now that the check is for
strictly-greater-than in:
{noformat}
if (os_time_get() - start > timo) { ... }
{noformat}
> hal i2c lockup on nrf platform if timeout is too short
> --
>
> Key: MYNEWT-865
> URL: https://issues.apache.org/jira/browse/MYNEWT-865
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: HAL
>Affects Versions: v1_2_0_rel
>Reporter: William San Filippo
>Assignee: Marko Kiiskila
> Fix For: v1_3_0_rel
>
>
> The nordic TWI (i2c) interface locked up when a too short timeout was
> applied. Not sure of all the details here but I believe another transaction
> was started and that this transaction caused the TWI interface to become
> unresponsive.
> The basic issue here is that the timeout is in os ticks and it is possible,
> given the current code implementation, that there is basically no timeout
> applied as a timeout of 1 os tick will give you a timeout of 0 to 1 os tick
> (in msecs).
> Another issue is that the code does not attempt to calculate whether the
> timeout is too short given the length of i2c data to be sent, the clock
> frequency and the time per os tick.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-865) hal i2c lockup on nrf platform if timeout is too short
[ https://issues.apache.org/jira/browse/MYNEWT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249945#comment-16249945 ] Simon Ratner commented on MYNEWT-865: - Not sure if "lockup" is an accurate description, but every subsequent transaction fails. Also, the issue isn't just that the timeout calculation is inaccurate. Even if the timeout is valid and legitimate (the i2c peripheral didn't respond or responds late), need to make sure subsequent transactions don't continue failing, i.e. any unexpected state is flushed from the bus before the next transaction. > hal i2c lockup on nrf platform if timeout is too short > -- > > Key: MYNEWT-865 > URL: https://issues.apache.org/jira/browse/MYNEWT-865 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: HAL >Affects Versions: v1_2_0_rel >Reporter: William San Filippo >Assignee: Marko Kiiskila > Fix For: v1_3_0_rel > > > The nordic TWI (i2c) interface locked up when a too short timeout was > applied. Not sure of all the details here but I believe another transaction > was started and that this transaction caused the TWI interface to become > unresponsive. > The basic issue here is that the timeout is in os ticks and it is possible, > given the current code implementation, that there is basically no timeout > applied as a timeout of 1 os tick will give you a timeout of 0 to 1 os tick > (in msecs). > Another issue is that the code does not attempt to calculate whether the > timeout is too short given the length of i2c data to be sent, the clock > frequency and the time per os tick. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
