[etherlab-users] Problem with rescan of slave(s)

[Gavin Lambert]

On 25 November 2016 06:47, quoth Frank Jeschke:
> Hello, we are using the etherlab master 1.5.2 and face a problem when nodes restart
> (here: after a firmware update). It looks like the fsm_master statemachine hangs while
> waiting for any kind of reply (at least this is what I could figure out).
> 
> For the firmware update we change to BOOTSTRAP mode, this resets the device to
> receive the firmware via FoE. After the firmware is installed the device is reset
> and starts operation (which we could verify). At this point the EtherCAT master
> does not recognises all or sometimes some of the slaves on the bus. I could verify
> this problem with two nodes, with more nodes it becomes more serious.

Are these your own slave devices?  Presumably yes, if you're wanting to do firmware updates.

Even if you have to reboot the slave firmware during the INIT to BOOT transition (eg. to load bootloader firmware), it's very important to avoid resetting the ESC during this transition (in fact try to never reset the ESC at all except on actual power cycle).

If you keep the ESC out of reset, then the link will not go down and you will not have this issue.

I can't verify at the moment but I'm reasonably sure that there's an official Conformance Test regarding this behaviour; the link is required to not be dropped during INIT -> BOOT or even BOOT -> INIT without a valid firmware upload in between.  (It's permitted to be dropped on BOOT -> INIT following a firmware upload -- though personally I found this too problematic on large networks, so my slaves don't do that and instead require a power cycle or a REBOOT broadcast command before they'll drop link and activate the new firmware.  If you can start the new firmware without dropping link at all, then that's even better.)

> We also faced a issue that the master requested the SDO dictionary during the FoE
> transfer. This led to a interruption of the FoE transmission, with this patch:
> https://github.com/synapticon/Etherlab_EtherCAT_Master/commit/085c278816730397eb9df6d808228c66dc09ccd6
> we could avoid the problem (AFAIK is  no other mailbox communication allowed in
> BOOTSTRAP mode).

You might want to give the unofficial patchset (https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme) a try.  (It's intended for PREEMPT_RT; there have been reports of problems using it with Xenomai.)

While it doesn't have anything that specifically fixes or blocks CoE in BOOT (or at least not that I recall), it does have several fixes for FoE and mailbox handling in general, and does disable the SDO dictionary fetching by default.

I've carried out fairly large scale firmware updates using this version, so I'm reasonably confident that it works.  But you'll still most likely need to stop the ESC from resetting.