search

cvra / can-bootloader

The bootloader used to flash our CAN-connected boards
BSD 2-Clause "Simplified" License
143 stars 51 forks source link

Ignore extended CAN frames #54

Closed msplr closed 9 years ago

msplr commented 9 years ago

The bootloader client should discard extended CAN frames. Otherwise it won't work with uavcan traffic during flashing.

antoinealb commented 9 years ago

Agree. Can you do it ? I think a simple filter in the platform-specific code would do it ?

msplr commented 9 years ago

I implemented the filter in the serial-can-bridge and master-firmware code. To make use of this the client needs to be updated and set a filter for IDE flag to false with corresponding mask to must match (true). (see can-bridge doc)

antoinealb commented 9 years ago

I think we also need to do a change on the stm32f3 can interface, don't we ?

msplr commented 9 years ago

No, this concerns only the CAN bridge communication between the PC and and the master board - no changes needed for the motor control firmware or bootloader. The changes on the master board firmware are the switch to the uavcan CAN driver.

antoinealb commented 9 years ago

What I meant is that currently can_interface_read_message doesn't filter out extended frames. Otherwise it will be confused if there is UAVCAN traffic during the flashing process.

msplr commented 9 years ago

if you mean the bootloader code: no, the filter is already configured to only accept standard CAN frames.

antoinealb commented 9 years ago

So I fixed it in d9d86d18debaba25e02bff50cd019061424d6908 in pure software. We must ignore those frames in software anyway, since some of them might fill the buffer before we configure the bridge.