S
Stéphane de Luca
I am developing a firmware update via CANbus 2.0B. The client is written in python to send the firmware binary file to the receiver (an esp32-based custom pcb equipped with a CANbus transceiver). The communication runs at 500kbps.
Simply put, the protocole I ended up with is as follows: the client opens the firmware file, read 8-byte chunk and transmits the chunk of the file, to the receiver, which keeps track of the chunk index, starting from 0 and incrementing. On the receiver, on chunk reception, the chunk is written to the flash via a RAM buffer. The receiver keeping track of the index on its side as well, it sends a message back (with a different arbitration id) that contains the index in the payload. So that the client can compare the receiver index with its own and potentially emit a transmission error if they mismatch. The file to transfer is about 1.4MB. The whole process takes about 8 minutes.
My messages use normal communication (aka not a listener nor a no-ack). It does not use CANbus filtering either.
That kind of handshake works nicely when the mac that bears an USB peak adapter which itsel is connected via two wires to the esp32 pcb can high/low connector.
Now, the receiver is actually a battery and the esp32 pcb set in its enclosure.
The battery is itself inserted in a transport robot. The battery communication port is connected to the comm port of the robot. That very CANbus port is located inside the chassis of the robot. But the robot has another CANbus port outside the chassis that is easily accessible.
So when I plug my peak to the « outside » port, and keep the robot turned off, the firmware update works nicely the same way it works in direct connection (aka straight to the battery), whilst I noticed a longer time to transfer (12 minutes).
Now, when the robot is turned on, the process stops working. It is kind of my messages are lost somewhere.
The CANbus communication itself seems to work: my client sees others standard messages coming from one of the robot devices. The robot itself has 3 devices connected to the CANbus. Those devices use 500kbps as well. From the 3 devices two use standard frames while the third uses extended frames.
The robot manufacturer says the bus is low loaded (around 5% of the maximum).
What would potentially be the source of the problem? What could I setup to better investigate the situation?
Simply put, the protocole I ended up with is as follows: the client opens the firmware file, read 8-byte chunk and transmits the chunk of the file, to the receiver, which keeps track of the chunk index, starting from 0 and incrementing. On the receiver, on chunk reception, the chunk is written to the flash via a RAM buffer. The receiver keeping track of the index on its side as well, it sends a message back (with a different arbitration id) that contains the index in the payload. So that the client can compare the receiver index with its own and potentially emit a transmission error if they mismatch. The file to transfer is about 1.4MB. The whole process takes about 8 minutes.
My messages use normal communication (aka not a listener nor a no-ack). It does not use CANbus filtering either.
That kind of handshake works nicely when the mac that bears an USB peak adapter which itsel is connected via two wires to the esp32 pcb can high/low connector.
Now, the receiver is actually a battery and the esp32 pcb set in its enclosure.
The battery is itself inserted in a transport robot. The battery communication port is connected to the comm port of the robot. That very CANbus port is located inside the chassis of the robot. But the robot has another CANbus port outside the chassis that is easily accessible.
So when I plug my peak to the « outside » port, and keep the robot turned off, the firmware update works nicely the same way it works in direct connection (aka straight to the battery), whilst I noticed a longer time to transfer (12 minutes).
Now, when the robot is turned on, the process stops working. It is kind of my messages are lost somewhere.
The CANbus communication itself seems to work: my client sees others standard messages coming from one of the robot devices. The robot itself has 3 devices connected to the CANbus. Those devices use 500kbps as well. From the 3 devices two use standard frames while the third uses extended frames.
The robot manufacturer says the bus is low loaded (around 5% of the maximum).
What would potentially be the source of the problem? What could I setup to better investigate the situation?