A Controller Area Network Layer for Reconfigurable Embedded System

1. A Controller Area Network Layer for Reconfigurable Embedded System Nithyananda Siva Jeganathan Masters Thesis Defense Department of Electrical and Computer Engineering University of Kentucky Lexington, KY October 3, 2007

2. Outline • Thesis Motivation • Reconfigurable Architecture background • Thesis Objective • CAN Background • CAN Applications • CAN Hardware Overview • CAN Protocol Overview • C_CAN Controller overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

3. Thesis Motivation • All safety-critical distributed systems need a reliable network for communication • The embedded network should also be fault-tolerant • Operate with limited services during faults and degrade gracefully in case of failures

4. Background • Reconfigurable distributed Apps. • Ideal platform for fault-tolerant systems • Faults will always occur • system should detect/isolate faults • Ardea is the reference framework • IDEAnix Framework • ENDURA network layer IDEAnix Framework

5. ARDEA Background Direction Graph • ARDEA Architecture • Framework for dynamic reconfiguration using Direction Graphs (DGs) • Supports Graceful degradation • Relies on Broadcast network for sending data between nodes • IDEAnix Framework • Provides application layer with features for reconfiguration • Location Transparency of Tasks/data • Handles packet routing between nodes/ modules

6. Thesis Objective • Embedded Network Driver for Use on Reconfigurable Architecture (ENDURA) • Broadcast type network with dynamic registering or unregistering of messages • Network Interface task using Controller Area Network (CAN) • ENDURA layer implementation is generic • Designed to match standard API calls • CAN layer can be replaced by any broadcast type network • Reusability of modules and dynamic addition of functionalities • Reduction of system complexity • Modules can be developed and tested independently

7. Outline • Thesis Motivation • Reconfigurable Architecture background • Thesis Objective • CAN Applications • CAN Background • CAN Hardware Overview • CAN Protocol Overview • C_CAN Controller Overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

8. CAN Applications Overview • Small Vehicle Applications • Light Electric Vehicles (LEVs) • Marine Applications • SeaCAN architecture • NAUTILE • Space Applications • SMART-1 satellite of ESA • SOFIA • Galileo Projects

9. CAN Background • CAN standard invented by Bosch GmbH for Automobiles in 1980s and widely used in embedded systems • ISO standardized the protocols • ISO 11898-1:CAN type A (11 bit Msg Ids) • ISO 11898-2:CAN type B (29 bit Msg Ids) • ISO 11898-3:Time Triggered CAN (TTCAN) • CAN protocol standardized in Data Link layer and MAC layer • Maximum Payload of 8 bytes • Maximum Bandwidth 1 MBits/Sec (upto 40m)

10. CAN Protocol Overview • CAN is broadcast type network • All nodes receive all the messages • Message filtering option on processors • Different Physical Layers as a rule, cannot interoperate • CAN bus is Wired-AND logic • Dominant bit is 0V & Recessive bit is +5V • If one node is transmitting 0, then the network is in that state (All other processors transmit a 1) • Acceptance Filtering is key to message Rx • Based on Message identifiers and network Tx is Big-Endian • 4 types of Packet Formats • CAN Data Frame, Remote Frame, Error Frame, Overload Frame

11. CAN Frame Format

12. Outline • Thesis Motivation and background • Objective and Problem statement • Embedded Network background • CAN Background • CAN Applications • CAN Hardware Overview • CAN Protocol Overview • C_CAN Controller overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

13. Silicon Laboratories C8051F04x • 8051 based 8-bit Microcontroller platform for ENDURA implementation • Implements CAN protocol using Bosch’s C_CAN protocol controller chip • Has 32 Message Objects that can be configured for Rx/Tx • Supports speed upto 1 Mb/s and 9 pin D-sub connectors are used

14. C_CAN Processor Block diagram

15. C_CAN Overview • C_CAN controls all CAN communication • C_CAN configurations are done through Registers • Protocol Control Registers • Control setting up of Bit-timing, Init sequences • Message Interface Registers • Msg Obj Configuration • Rx/ Tx control (Identifier Masks) • Reading/ Writing Data, ID • Message Handler Registers • Status of Msg Obj (NewData, Interrupt, Tx Rqst)

16. ENDURA Block Diagram

17. ENDURA Design Details • The ENDURA layer is a generic network implementation for Reconfigurable architecture • ENDURA layer for CAN is modularized as: • Initialization API • API Prototype: Void Init_network(void); • Initializes the bit-timing, BRP registers • Allocates and initializes the Data-structures for ENDURA • Sets the Init bit to 0 and starts CAN engine • This API has to be invoked before the node can start communicating on the network

18. Register Module Flow chart

19. Register Module • API Prototype: uint8 reg_pkt(ulong msg_id); • Verifies if the Message Id entered is valid or not been registered already (Msg ID 0 is invalid on CAN bus) • Locates a vacant Message Object number for config • Sets the Arbitration bits on IF1 ARB1 and IF1 ARB2 registers • Sets MsgValid bit on IF1 ARB2 Register • Sets UMask values in MSG Control Register to register for range of Msg ids • Enables the Interrupts for the Msg Obj when successful RX of a packet in MSG Control Register • Writes into IF1 Command Req Reg with the Msg Obj Number

20. Unregister Module • API Prototype: uint8 unreg_pkt(ulong msg_id); • Verifies if the Message Id entered is valid or not been unregistered already (Msg ID 0 is invalid on CAN bus) • Locates the corresponding Msg Obj number configured for receiving the packet • Clears the IF1 Command Mask register values • Clears the Arbitration bits on IF1 ARB1 and ARB2 registers • Clears the MsgValid bit on IF1 ARB2 Register • Clears the MSG Control Register • Writes into IF1 Command Req Reg with the Msg Obj Number

21. Send Packet API

22. Send Packet Module • API Prototype: uint8 send_pkt(ulong msg_id, ulong msg_data); • Send_pkt API sends a packet of given message id (11 or 29 bits) and payload on to the CAN bus • Send_Pkt API uses IF2 Registers for Msg obj config • Pre-defined Msg obj is chosen for sending packets : • Sets the IF2 Command mask register to write • Sets the Arbitration bits on IF2 ARB reg to 11 or 29 bit ids • Sets the MsgValid bit on IF2 ARB2 Register • Writes into IF2 Command Req Reg with the Msg Obj Number to send the packet on the network

23. Receive Packet Module • API Prototype: uint8 get_pkt(ulong *msg_id, ulong *msg_data); • get_pkt API fetches the latest message identifier and payload • The Get_pkt API reads the new Data registers to identify the message object that has been updated • Returns the message Id and Payload from the software buffer for the message object

24. CAN ISR Flow chart

25. Interrupt Service Routine • CAN Controller when configured correctly can trigger an interrupt (#19) • After successfully sending a packet • After successful reception of packet • If Error packet is received on CAN bus or error in Tx • Receive packet interrupt handling: • Clear the Status interrupt • Reads the data from NewData Registers to identify the message object that has the latest data • Copies the Message Object information onto Software Buffer or Send to queue • Transmit Packet interrupt handling: • Clear the Status interrupt • Optional can be used in fault-tolerant implementations • Error Interrupt handling • Clear the Status interrupt • Can be used by network fault-detection/ isolation modules

26. ENDURA Translation Module Translates A CAN 2.0 A type packet to 2.0B type and vice-versa

27. ENDURA Validation • ENDURA layer subjected to following tests: • CAN Conformance test • Performance Tests • Bandwidth Tests • Latency Tests • Endurance Tests • Sporadic packet Tests

28. ENDURA Performance Data • CAN Conformance test • All modules meet the CAN protocol conformance • Performance Tests • Endurance Test • No dropped packets at 10ms delay in packets • Pkts sent = 14,406,543 Pkts dropped = 0 • Sporadic Packet Tests • Packets sent at 1000ms, 500ms, 100ms, 50ms, 10ms rate • Bandwidth Tests • Maximum Bandwidth measured with IDEAnix = 100 KBPS • Bottleneck due to OS context switching time • Latency in sending a packet through the CAN controller

29. BW Analysis- Packets Received rate Packet Rate Vs Packets Rxd

30. BW Analysis- Packets Drop rate Packet Rate Vs Packets Dropped

31. Latency Test Measurement

32. Latency Test Data • Latency Tests • RX packet latency in ENDURA layer (T1) = 110 μSecs • RX MeRL processing latency (T2) = 756 μSecs • RX packet latency in CAN application(T3) = 856 μSecs • TX packet latency in ENDURA layer (T4) = 924 μSecs • TX packet latency in CAN application(T6) = 9 mSeconds • Time taken by C_CAN processor to TX a pkt = 110 μSecs • Max Bandwidth that can be realized = 120 KBits/Sec

33. Latency Test Timing Diagram

34. Outline • Thesis Motivation and background • Objective and Problem statement • Embedded Network background • CAN Background • CAN Applications • CAN Hardware Overview • CAN Protocol Overview • ENDURA design • ENDURA Validation • Future enhancements • Conclusion

35. Future Enhancement • CAN Bandwidth can be improved • By improving the OS Time Tick from 10 ms • By varying the No. of OS ticks per sec from 100 • CAN Send Packet Latency can be improved • By routing the inter-module packets through the ENDURA layer instead of IDEAnix • This improves latency by 10 times • Implement CAN Gateway nodes capable of communicating to other embedded networks • CAN to Wireless Network gateway (for extending CAN network) • For forming Ad-hoc networks

36. Conclusion • Provides a fault-tolerant platform for communication between nodes • Generic network task framework that can be ported to any broadcast type embedded network • Provides an infrastructure for reconfigurable architecture to perform dynamic reconfiguration • Realization of soft real-time distributed system made possible

37. ?

38. Thank you!

39. Fin!