Tim, See https://github.com/apache/nuttx/issues/3927
David -----Original Message----- From: Alan C. Assis <acas...@gmail.com> Sent: Wednesday, August 9, 2023 3:47 PM To: dev@nuttx.apache.org Cc: Pavel Pisa <pp...@pikron.com> Subject: Re: CAN TX fail handling Hi Tim, Agree! This behavior could be implemented in the driver, for example using some elapsed time. But again, it needs to be analyzed careful to avoid introduce sometime too specific for a user needs. Currently the can_close() try to wait for the TX complete that could never happen because this issue. If you implement the idea of resetting the CAN controller in the can_close() you need to guarantee that it will be reinitialized correctly, because in can_open() it expects the CAN controller in working state. BR, Alan On 8/9/23, Tim Hardisty <t...@jti.uk.com.invalid> wrote: > Thanks Alan, > > I can see that a timeout/retry in detail would be hardware dependent. > But in the absence of "something," code can send a message, but have > no idea that it hasn't actually been sent, then try and close the "file" > and the thread will hang indefinitely. I think we need something that > reports the fail so some kind of recovery/reset can be attempted? > > Perhaps the "close" could be wrapped with something to deal with this? > Or the open mode needs to be different somehow? > > POSIX/Linux type programming is new to me, after decades of bare-metal > type software dev where I'm in total control albeit unique to a > given/chosen processor, so any suggestions would be very welcome. > > On 09/08/2023 19:56, Alan C. Assis wrote: >> 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-Retr >> ies >> >> 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 )? >>> >>> > -- > > Regards, > > Tim Hardisty > > > A picture containing text, clipart Description automatically generated > > > > +44 (0) 1305 534535 > > > > <http://www.jti.uk.com/> > > > > JTi.uk.com <https://www.jti.uk.com/> > > > > <https://www.facebook.com/JTinnovations/> > > > > \JTinnovations <https://www.facebook.com/JTinnovations/> > > JT Innovations Ltd. > > Registered office: 36 East St, Weymouth, Dorset, DT3 4DT, UK. > > Company number 7619086 > > VAT Registration GB 111 7906 35 >
