You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When doing async SPI reads, the status code from DSPI_MasterTransferNonBlocking is ignored. This means that the context is not unlocked in spi_context_release even though an error condition is present.
I've seen a wide range of behaviour that I believe is caused by this bug. Sometimes, an imprecise bus error is produced, sometimes the board will just reset and sometimes, the board gets unresponsive and requires a hard reset to return to function.
To Reproduce
I've seen this issue on a custom board where we use SPI to read ADC samples from a streaming ADC chip. The driver reads samples from the ADC chip with a 2KHz frequency. Occasionally, the driver will attempt to read a sample before the previous read was finished, resulting in a busy bus and this will occasionally cause the aforementioned crashes, stalls etc.
Expected behavior
I would expect that the spi driver is able to gracefully handle a busy bus without crashing the kernel.
Impact
This is a showstopper as the board does not always restart when the error happens, forcing a manual reset of the board.
Environment:
Ubuntu 18.04
SDK 0.10.3
Zephyr 1.14
Custom K64f
The text was updated successfully, but these errors were encountered:
Describe the bug
When doing async SPI reads, the status code from
DSPI_MasterTransferNonBlocking
is ignored. This means that the context is not unlocked inspi_context_release
even though an error condition is present.I've seen a wide range of behaviour that I believe is caused by this bug. Sometimes, an imprecise bus error is produced, sometimes the board will just reset and sometimes, the board gets unresponsive and requires a hard reset to return to function.
To Reproduce
I've seen this issue on a custom board where we use SPI to read ADC samples from a streaming ADC chip. The driver reads samples from the ADC chip with a 2KHz frequency. Occasionally, the driver will attempt to read a sample before the previous read was finished, resulting in a busy bus and this will occasionally cause the aforementioned crashes, stalls etc.
Expected behavior
I would expect that the spi driver is able to gracefully handle a busy bus without crashing the kernel.
Impact
This is a showstopper as the board does not always restart when the error happens, forcing a manual reset of the board.
Environment:
The text was updated successfully, but these errors were encountered: