Hi Javier, I think it's a regression from the IOB rewrite.
The original implementation added the timestamp before calling either devif_conn_event or can_data_event. https://github.com/apache/nuttx/blob/55d9e5f7af05e75ca62f57863b880d723aa83c56/net/can/can_callback.c#L123-136 I think moving the code up would fix it. Yours sincerely, Peter van der Perk -----Original Message----- From: Javier Casas Marin <javierca...@geotab.com.INVALID> Sent: Wednesday, March 5, 2025 2:27 PM To: dev@nuttx.apache.org Subject: socket CAN timestamp missing Hi Nuttxaddicts, After configuring the CAN socket with SO_TIMESTAMP, the application reading the socket is sometimes getting an empty timestamp in some situations. I've been debugging this issue and I this is what I found: There are two paths when receiving a CAN frame from the interrupt, if there is someone waiting for a frame, the can_recvfrom_eventhandler callback is called to deliver the frame to the application, otherwise the frame is stored in the read-ahead list. When there is no listener available the timestamp is generated in the can_callback function just before calling can_data_event to store the CAN frame in the read-ahead list. But, if there is a listener waiting, the can_recvfrom_eventhandler is called and the timestamp is not generated at all, so the recvmsg call in the application side returns an empty timestamp. I think this is a bug. Why is the timestant not added in the explained case? Adding it in the can_recvfrom_newdata function solves the issue. Javier Casas Marín Geotab Senior Embedded Systems Developer Direct Toll-free Visit +34 900 535 371 http://www.geotab.com/es Twitter <https://twitter.com/geotab> | Facebook <https://www.facebook.com/Geotab> | YouTube <https://www.youtube.com/user/MyGeotab> | LinkedIn <https://www.linkedin.com/company/geotab/>
