Pavel Pisa commented on a discussion on cpukit/dev/can/ctucanfd/ctucanfd.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108448 > + } > + > + return ret; > +} > + > +/** > + * @brief This function issues software reset request to CTU CAN FD. > + * > + * @param priv Pointer to private CTU CAN FD structure. > + * > + * @return 0 for success, -ETIMEDOUT if CAN controller does not leave reset > + */ > +static int ctucanfd_reset( struct ctucanfd_priv *priv ) > +{ > + uint16_t dev_id; > + int i = 100; The maximal time of reset is given by the IP core clocks and they define delay per read attempt so it should be safe and generally it is fast. The required time 20 ns for 100 MHz clocks for hardware reset and no wait for the software one, see [2.2 Reset](https://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf). So the check is there to not stuck when there is problem with FPGA synthesis or some clocks blocked, not configured. When AXI clocks are missing on Zynq, then it will not help because CPU core is stuck on the access completely. So some logic with timer setup etc. will not help there. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108448 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
