[etherlab-users] How to reboot a slave

[Gavin Lambert]

On 12 June 2018 19:33, quoth Joye Laurent:
> Here are my questions:
> - Should it be possible to reboot a slave by writing 3 times in the related
> register? If no, is it possible to reboot a slave by using your library?

It is generally not possible to reboot a slave by using register requests directly -- the slave requires the register writes to be in three consecutive frames, which is not possible to arrange when the master is doing its own thing.

It is possible to reboot a slave using the dedicated reboot command -- provided that the slave has actually implemented it.  An ESC-based slave will trigger a pulse on its RESET pin when this sequence is received but it's up to the slave device implementation what actually happens after that.

It's best to do it only when you don't have anything else of note running on the network, both to help ensure that the frames are sequential without other activity and because rebooting a slave will "break" the network anyway.

> - What is the best solution to reboot a slave device?

The reboot command is the method that I use.

Slave devices are also recommended to reboot automatically on a BOOT -> INIT transition if firmware was successfully updated (and avoid rebooting if the update failed or no update was attempted).

Failing either of these methods, an external power cycle may be needed.

> - Is it possible to read and write the EEPROM content by using the read and
> write register requests?

It is possible, but a little complex since you'll have to manipulate multiple registers in the right order.

>From the command line, you can use "ethercat sii_write" to write new SII EEPROM contents to the device.

The "ethercat" command line tool uses ioctl APIs under the hood to request that the master carry out various management activities such as SII writing or rebooting.  It is possible to call these from your application as well, with appropriate care; though technically this is not recommended.  Perhaps a better option might be to implement a separate firmware loader tool or script that runs while your real app is shut down -- but that depends on how your system is set up and who will be doing updates.