hot swapping low-voltage can-fd boards (SAMC21)

dc42

@tristanryerparke what echo commands does daemon.g generate if you boot up with the sammyc21 connected, then remove 5V power from it for several seconds, then reapply 5V power?

tristanryerparke

@dc42 the "found board 1" messages continue when removing 5V power from the sammyc21, and continue after re-applying 5V.
Same thing happens when removing canL+canH+5V+GND (simulated pogo pin situation).
My initial test from the first post was just removing canL and canH.
Thanks for the quick response,
T

dc42

@tristanryerparke thanks. So are you saying that:

If the SammyC21 is connected when you start the main board, it recognises it (as expected)
If you then disconnect the SammyC21 it doesn't recognise that it has been lost (this is also expected behaviour for the current firmware)
If you power up with the SammyC21 not connected, and subsequently connect it, it is recognised that a board has been connected but the unique ID is not matched

tristanryerparke

@dc42 Yes, and in the third scenario where the SammyC21 is connected, the unique ID in the object model browser reads "".

tristanryerparke

@dc42 Is there any way to "refresh" the CAN-FD bus with the current firmware? If not what are you thinking for the future of this kind of functionality.
Best,
T

dc42

@tristanryerparke you can send a M999 B# command (where #is the CAN address of the SammyC21). That should cause SammyC21 to reset and then send its details again.

dc42

@tristanryerparke I have not been able to reproduce the issue you reported. If I power up the main board with the sammyc21 not powered, then I later provide power to the sammyc21, the unique Id does appear in the object model. However, I am running firmware 3.5.0-beta.3 on the main board and 3.4.3 on the sammyc21.

tristanryerparke

@dc42 I just did a little more testing and also upgraded to 3.5.0-beta.3 on both boards.

two situations:

When powering the mainboard up with power disconnected from the sammyc21, and then connecting it, I see a similar result to what you mentioned, where the unique Id eventually appears in the OM browser.
When powering the mainboard up with (only) can disconnected on the sammyc21, and then connecting the bus, the OM fields for that board are unpopulated and only the address field is correct. This state does not seem to go away unless I send a M999 B124 to reset the board, and then the fields are populated correctly.
When powering up the mainboard with can and power disconnected from the sammy, and then connecting both, I get the same result as my first bullet point.

Is there any benefit to using 3.4.3 on the sammy like in your test case?
Thanks,
T

dc42

@tristanryerparke said in hot swapping low-voltage can-fd boards (SAMC21):

Is there any benefit to using 3.4.3 on the sammy like in your test case?

Probably not. I will try to replicate your results using 3.5beta3.

dc42

@tristanryerparke I have now tested using 3.5beta3 and the uniqueId field does get populated when I make the CAN connection after powering up both the main board and the SAMMYC21.

The only reason I can see why the uniqueId would not get populated is if the SammyC21 was running firmware earlier than 3.4.0. But in that case the uniqueId field would never be populated.