Michal Lenc created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1183
Project:Branches: michallenc/rtems:sja1000 to rtems/rtos/rtems:main Author: Michal Lenc ## Summary This commit adds support for a stand alone SJA1000 CAN controller. This is classical CAN only capable controller, so no FD support here. The driver's implementation is similar to CTU CAN FD, thus interrupt handler triggers a semaphore in main worker thread that takes care of handling interrupts and receiving and sending messages. The controller utilizes its one TX buffer for sending messages with abort function available if higher priority message is present in the software queue. The initial idea was this controller would be a good simple template example for future CAN controllers using RTEMS stack, but we run into several issues during the development. The most notable one is RX interrupt not cleared on interrupt status register read and not even on RX interrupt disable, but only after RX buffer release command is sent. This caused problem in our design where interrupt handler only masks the interrupts and wakes up worker thread and let it process the message. SJA1000 can't unfortunately mask interrupts, just disable them, which clears the interrupt status register and still doesn't disable RX interrupt. Therefore we have to disable RX interrupts (along with all others) read the first RX message from the buffer, store it in the internal sja1000 structure and then release the buffer -> this ensures RX interrupt is no longer triggered. The rest of RX messages is read from worker thread along with the handling of other interrupts. ### Testing The controller was tested with our test suite available in OTREES gitlab repository: https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd (implementation of sja1000 in [its own branch](https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/sja1000?ref_type=heads)). Tests were done on Xilinx Zynq platform both against CTU CAN FD RTEMS implementation and against Linux SocketCAN with CAN to USB converter (as a listening device for debugging). This includes two way communication tests (both controllers send 2k CAN messages) and chip stop tests (ensuring the software queue and hardware TX buffer are correctly flushed). Pavel Píša @ppisa tested the controller for abort capabilities and latency on the original NXP PCI SJA1000 CAN cards on x86. One controller was trying to send mix of `0x700` and `0x20` messages while other was spamming the bus with `0x500` mid priority messages, thus creating priority inversion issue. Additional CTU CAN FD controller on Zynq was used to generate `0x600` messages to ensure the bus is 100 % filled with mid priority messages. The monitoring below shows the high priority messages `0x20` got to the bus, therefore proving the abort capability of the controller. ``` can5 500 [8] 41 30 00 00 00 00 00 00 can5 600 [1] F6 can5 500 [8] 42 30 00 00 00 00 00 00 can5 600 [4] 0C 38 C2 60 can5 500 [8] 43 30 00 00 00 00 00 00 can5 600 [3] 17 58 71 can5 500 [8] 44 30 00 00 00 00 00 00 can5 020 [8] 00 DC C5 68 26 41 00 00 can5 500 [8] 45 30 00 00 00 00 00 00 can5 020 [8] 01 01 C9 68 26 41 00 00 can5 500 [8] 46 30 00 00 00 00 00 00 can5 020 [8] 02 0C CB 68 26 41 00 00 can5 500 [8] 47 30 00 00 00 00 00 00 can5 020 [8] 03 0D CD 68 26 41 00 00 can5 500 [8] 48 30 00 00 00 00 00 00 can5 600 [8] 60 BF D0 6B 45 31 AA 2E can5 500 [8] 49 30 00 00 00 00 00 00 can5 600 [0] can5 500 [8] 4A 30 00 00 00 00 00 00 can5 600 [8] EF 93 45 0C 7A 29 08 55 can5 500 [8] 4B 30 00 00 00 00 00 00 ``` ## Generative AI <!-- If you have used AI please use the "AI Contribution" template otherwise leave this blank see our fulls statement at https://www.rtems.org/generative-ai/--> <!-- Default settings, if it is a dropdown it will set after submission --> -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1183 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
