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-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 )? >>> >>> > -- > > 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 >
