Hi Tim, I think that the default behavior of CAN Controller is trying to send indefinitely a message, some HW can define some retry limit.
Please take a look: https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retries So, I'm not sure if it will make sense to implement a CAN TX timeout on NuttX side, since this behavior could be HW dependent. BR, Alan On 8/9/23, Tim Hardisty <t...@jti.uk.com.invalid> wrote: > I am now cracking on with the app for my custom board, and in parallel > writing a production board-test app. > > In trying to cover potential board faults, I have found that if there's > something that prevents a CAN message reaching an endpoint/destination, > the CAN transmitter (of course, as I understand it) is continuously > retrying the message send, meaning the test app hangs when you try and > close the file once the test has been deemed to fail. That is "by > design" in the higher (i.e. non-arch specific) can code as it waits for > the TX FIFO/queue to empty until the close is allowed. > > What is the correct POSIX way to handle this error condition? > > Might it be better to use Socket CAN, for example, assuming it has > better error handling by design, or is the NuttX CAN "system" > fundamentally missing something to handle this (or, more likely, I've > just missed it )? > >
