summaryrefslogtreecommitdiff
path: root/SjaCanTestNode.mdwn
blob: d83fc6c32523db6d089e14091dba7ccc22a8afdd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
# <a name="PIC16F877/SJA1000 CAN Test Node"></a><a name="PIC16F877/SJA1000 CAN Test Node "></a> [[PIC16F877]]/SJA1000 CAN Test Node Information

Our first version of CAN nodes had a Microchip [[PIC16F877]] and a Philips SJA1000 CAN protocol chip on it. We made a "test" node, so the FC people would have a working CAN node in order to test the CAN driver and and FC software.

## <a name="Hooking it up"></a> Hooking it up

1. Screw in the CAN cable (you'll need a teeny weeny screwdriver for those 0.1" euroterm blocks.
2. Screw in the power cable from the "wallwart" power supply
3. When you're ready, plug it in.

If the red error LED goes on, or something seems to have locked up, just cycle the power on the board by unplugging and plugging the power supply.

**Remember**, when it doubt, power cycle ;)

## <a name="Behaviors"></a> Behaviors

### <a name="Broadcast CAN messages"></a> Broadcast CAN messages

- Once a second, the node will broadcast CAN message ID = 0x7FC = 0b111 1111 1100 with 8 bytes of data. Those 8 bytes are a BCD counter, from 00000000 to 99999999.

### <a name="Triggered CAN messages"></a> Triggered CAN messages

- If you push the button on the board, CAN message ID = 0x7FD = 0b111 1111 1101 will be sent on the bus, with the following random data:
  - Data[0] = gcSystemError; // The current system error numer
  - Data[1] = Read\_SJA(SJA\_ECC); // SJA errors
  - Data[2] = Read\_SJA(SJA\_RXERR); // the number of SJA receive errors
  - Data[3] = Read\_SJA(SJA\_TXERR); // the number of SJA transmit errors

### <a name="Received CAN Messages"></a> Received CAN Messages

- CAN Message ID 0x7FE = 0b111 1111 1110 with data[0] &gt; 0x00 turns on Green LED #1. If data[0] is 0x00, Green LED #1 will turn off.

- CAN Message ID 0x7FF = 0b111 1111 1111 with data[0] &gt; 0x00 turns on Green LED #2. If data[0] is 0x00, Green LED #2 will turn off.

### <a name="LEDs"></a> LEDs

<table border=1 cellpadding=0 cellspacing=0>
  <tr>
    <td> ERROR_LED </td>
    <td> RA0 </td>
    <td> RED </td>
    <td> Firmware error: PIC is probably locked up. </td>
  </tr>
  <tr>
    <td> OVERFLOW_LED </td>
    <td> RA1 </td>
    <td> YELLOW </td>
    <td> the SJA&#39;s receive buffer has overflowed: too many messages, too fast. </td>
  </tr>
  <tr>
    <td> CANERR_LED </td>
    <td> RA2 </td>
    <td> YELLOW </td>
    <td> Passive or active error state: nothing is listening on the bus, wrong bit rate, etc. </td>
  </tr>
  <tr>
    <td> BUSERR_LED </td>
    <td> RA3 </td>
    <td> YELLOW </td>
    <td> Hard error on the CAN bus: bit stuffing violation, CRC error, etc. </td>
  </tr>
  <tr>
    <td> GREEN1_LED </td>
    <td> RA4 </td>
    <td> GREEN </td>
    <td> CAN triggered LED </td>
  </tr>
  <tr>
    <td> GREEN2_LED </td>
    <td> RA5 </td>
    <td> GREEN </td>
    <td> CAN triggered LED </td>
  </tr>
</table>

- If the node receives an CAN ID it doesn't recognize, it turns the OVERFLOW\_LED, CANERR\_LED, and BUSERR\_LED. Now _that's_ a stupid behavior. Sorry.

- Note the CANERR\_LED lights up if there's nothing listening on the bus - the attempted 1Hz messages will be stuck until there's another node listening on the bus, since there's that pesky (but necessary) "ACK" field in the CAN bus transmit sequence.