And the number of such attempts is much more than two (in my practice with CAN I met only with such settings when CAN-node (TMS-microcontrollers, SJA1000 and now with ESP32) retransmit the same packet automatically endlessly). But that does not mean that write is totally failed - SJA1000 (and I hope ESP32 too) will just switch to receive mode and attempt to start transmission again automatically after reading of packet is finished. For example "Arbitration Lost Interrupt" (ESP32_CAN_INT_ARB_LOST) should occur each time when some other CAN-node has started transmission at the same time as we and his CAN-id is less than our (has higher priority). As I undestand it, some of the error interrupts are just warnings. I think everything is fine except of handling error interrupts - I think that reaction is too strong.
Wd4100 server startup failed 0xd9 code#
I have not tested your code but I have carefully looked at it. It's easy!įor the thrd module, relevant files are thrd.h and thrd.rst. Just fork the repository and create a pull request. Any clarifications and typo fixes are very welcome.
The library reference section of the documentation is mostly generated from comments in the C header files, and descriptive text and images are added in the doc folder. Maybe additional configuration is required, I don't know.
Wd4100 server startup failed 0xd9 driver#
All interrupt sources areĮnabled when the CAN driver is started, so it's a bit strange that the interrupt handler was not called. Though, I tested to write a CAN frame with the ESP32 CAN GPIOs unconnected, and the interrupt handler was never called. There are status bits and interrupt enable bits for various errors. That said, I don't know if the SJA1000 hardware in the ESP32 can do this, but it looks promising reading the datasheet for the SJA1000. There is a short contribution how-to here.Īdding a timeout in thrd_suspend_isr() is a workaround in my opinion, the hardware should call an interrupt handler when an error is detected on the bus. The CAN driver is implemented in the Simba repository, so fork that repository. The Pumbaa repository wraps the Simba an Micropython repositories. I have found two typos in simba-os docs: in description of functions "thrd_suspend" and "thrd_suspend_isr" - there is no macro ETIMEOUT, but there is ETIMEDOUT (I think these typos are coming from comments in cores\pumba\simba\src\kernel\thrd.h) If you are interested, I will gladly send my changes but I could not understand what repository should I clone, modify and make a pull-request to. But for the present I'm looking for debug ouput from this "isr(.)" function to test if those interrupts are arriving in this situation. May be the better way is to call thrd_resume_isr(.) from "can_port.i :: static void isr(void *arg_p)" while handling error interrupts. And now Can.write(.) in absence of receiver raises an exception in 2 seconds. Right now in my installed version of Arduino cores I have modified pumbaa\simba\src\drivers\ports\esp32\can_port.i :: write_cb(.) : in call to thrd_suspend_isr(.) I have replaced NULL parameter to time_t* with 2 seconds. So in absence of receiver Can.write(.) hangs forever. Pumbaa\simba\src\drivers\ports\esp32\can_port.i :: write_cb(.) -> thrd_suspend_isr(NULL)Īnd the thread suspends until "can_port.i :: static void isr(void *arg_p)" calls thrd_resume_isr(.)īut this call is issued only in handling of TX interrupt. Simba/blob/master/src/drivers/can.c :: can_write(.) -> chan_write(.) Pumbaa\src\module_drivers\class_can.c :: class_can_write(.) -> can_write(.) I think I have found where Can.write(.) hangs.