I'm not sure that's correct either. Generally the error indication is to provide information about a refusal to enter a higher state, and can be acknowledged. So the "correct" flow would be:
1. Slave is in BOOT and has received invalid firmware; if possible, signal an FoE error or log a Diagnostics message at this time. 2. Master requests INIT. 3. Slave acknowledges INIT with no error. 4. Master requests PREOP. 5. Slave refuses PREOP by replying with INIT + ERROR. 6. Master acknowledges ERROR. 7. Slave returns to INIT (clears ERROR). 8. Repeat 4-7 if master re-requests PREOP. Again, have a look at ETG1000.6 6.4.1.4. > -----Original Message----- > From: Knud Baastrup [mailto:k...@deif.com] > Sent: Thursday, 6 August 2015 20:26 > To: Gavin Lambert <gavin.lamb...@compacsort.com> > Cc: etherlab-dev@etherlab.org > Subject: RE: [etherlab-dev] [PATCH] My patchset roundup July 2015 > > Hi Gavin, > > We do enter state INIT, but with the Error indication flag set (due to invalid > firmware) and that is why I wrote "prevented to enter state INIT", which I > agree could be misunderstood. > > BR, Knud > > > -----Original Message----- > From: Gavin Lambert [mailto:gav...@compacsort.com] > Sent: 6. august 2015 09:42 > To: Knud Baastrup > Cc: etherlab-dev@etherlab.org > Subject: RE: [etherlab-dev] [PATCH] My patchset roundup July 2015 > > Hi Knud, > > Thanks for sharing the updates. > > Regarding the description of the update for patch 0008, though, this puzzles > me a little. > > According to ETG1000.5 (specifically 6.2.1.3.8 "Stop Bootstrap Mode" > service, and also ETG1000.6 6.4.1.4 #51 and #57), a slave is not permitted to > refuse the transition from BOOT to INIT (this generally applies to all of the > other "upwards" transitions as well). > > Of course the master still needs to be able to cope with it anyway (a crashed > slave may fail to respond to all transitions until power cycled, although this is > not the same as a refusal), but it's not something that's supposed to happen. > > I assume this is one of your own slaves? My reading of the standards > suggests that in the case of invalid firmware a more appropriate response > would be to allow the transition to INIT (and back to BOOT), but refuse > transition to PREOP with AL status 0x0014 ("no valid firmware"). > > Having said that, there's very little information in the standards (at least that > I've found) about how firmware updates are recommended to work > (presumably because this is very hardware-specific), so it wouldn't hurt to > ask about it on the ETG forums, if you haven't already. > > Regards, > Gavin Lambert > > > -----Original Message----- > > From: Knud Baastrup [mailto:k...@deif.com] > > Sent: Thursday, 6 August 2015 19:05 > > To: Gavin Lambert > > Cc: etherlab-dev@etherlab.org > > Subject: RE: [etherlab-dev] [PATCH] My patchset roundup July 2015 > > > > Hi Gavin, > > > > I look forward to try out the complete access support that you have > > implemented. We have several cases where we believe this feature can > > be very useful. > > > > > > I have done a few updates on some of the knud-xxxxxxx patches as well, > > which includes: > > > > Correction to 0003-Eoe-mac-address-now-derived-from-unique- > mac.patch: > > Added new line to EC_SLAVE_INFO > > > > Correction to 0008-Clear-slave-mailboxes-after-a-re-scan.patch: > > Now assuming that the slaves mailbox data is valid even if the slave > scanning > > skipped the clear mailbox state, e.g. if the slave refused to enter > > state > INIT. > > This correct an introduced bug where invalid application firmware > > (that prevented the slave module to enter state INIT) could prevent > > mailbox communication (FoE) in state BOOT. > > > > New 0017-EoE-processing-is-now-only-allowed-in-state-PREOP-SA.patch > > The patch ensure that EoE fragments only is forwarded in state PREOP, > > SAFEOP and OP and not in state BOOT that is mainly (only?) intended > > for bootstrapping using FoE. The patch corrects an issue where EoE > > fragments can interrupt a successful FoE firmware upgrade in state > > BOOT despite that the slave code is restricted to only use FoE in > > state BOOT. In our case we > use > > a common bootloader for all I/O modules that only supports FoE. The > > bootloader will however still use mailbox buffer to receive EoE > > fragments (and additional to inform the Master that EoE is not > > supported), which in some cases can prevent the execution of a FoE > request. > > > > Mvh. Knud > > > > > > -----Original Message----- > > From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On > > Behalf Of Gavin Lambert > > Sent: 10. juli 2015 09:14 > > To: etherlab-dev@etherlab.org; Florian Pose > > Subject: [etherlab-dev] [PATCH] My patchset roundup July 2015 > > > > Hi all, > > > > It's been a while since I last posted my current patchset for > > Etherlab, so > it > > seemed like a good time to share the newest ones. > > > > As with the last set, this is based on stable-1.5 (specifically > > 4b0b906df1b40a1b5610282117b2c22581890575) and contains both my own > > patches and patches from others in the community, and I'm sharing them > > in case people find them useful and that hopefully they'll make it > > into > mainline. > > > > Having said that, it appears that some of the patches in here have > > made it into the default branch already; I haven't had time yet to > > inspect them > and > > rebase my patchset onto that branch, but it's on my TODO list. :) > > > > The series file included in the archive shows the intended application > order > > (though you'll probably want to skip some of them if you're on default > > already). > > > > Short descriptions (commit notes) are at the top of each patch; > > detailed descriptions for the older patches can be found in previous > > emails, but > I'll > > give a bit more background on the newer patches below. The older > > patches are unchanged except for possible defuzzing. > > > > Before that though, just a reminder that patch 0006 > "dc_sync_vs_sys_time" > > is only a partial fix; it works for slaves that have AssignActivate > > bits > 0x3000 > > set, and that don't mind the offset between SM events and SYNC events > > changing, but won't help other slaves -- they'll need a more > > comprehensive fix (fully recalculating the Sync Start Time). It's > > probably not > something I will > > do because my slaves do work with this, and I'm not sufficiently > > familiar > with > > the way DC sync is calculated in Etherlab. > > > > The new patches are the gavinl-2000 series, as follows: > > > > gavinl-2001-reg_readwrite: > > This adds an API "ecrt_reg_request_readwrite" and tool command > > "reg_readwrite" which will write register data and read back the > > values before the write in a single FPRW datagram. This can be useful > > to ensure that the data is coherent and you don't miss an update. It > > assumes Knud's > rt- > > mutex patch has been applied; if not you'll have to switch the locking > calls > > back. > > > > gavinl-2002-reg_req_info: > > This enhances some of the debug-level logging for register requests. > > > > gavinl-2003-sdo_complete_upload: > > This adds an API "ecrt_master_sdo_upload_complete" and extends > tool > > command "upload" to support reading entire objects from a slave via > > SDO Complete Access (where supported by the slave). As with the > > existing download functionality only Complete Access from subindex 0 > > is supported; future extension might be to support access from index 1 > > as well. Note > that > > when using the tool "upload" it will default to the "octet_string" > > data > type, so > > you can use something like "ethercat upload -p0 INDEX | hd" to see the > data > > formatted nicely. It also assumes use of Knud's rt-mutex patch. > > > > gavinl-2004-sdo_write_size: > > This might be a little more controversial. :) This modifies the > > "ecrt_sdo_request_write" API (so it's a breaking change) to also > > include > the > > size of data to be written (this must be less than or equal to the > > size > specified > > at the time the request was created). Combined with the existing > > "ecrt_sdo_request_index" API, this allows you to re-use one request > > object for any SDO on the same slave, provided the initial size is large > enough. > > Previously you had to use at least one object per different object > > size, > as > > there was no way to set the write size other than at creation time, > > and > the > > write size was also altered whenever you did a read. (Possible > non-breaking > > alternative would be to make "ecrt_sdo_request_set_data_size" or > > something, but that seems messier.) > > > > gavinl-2005-sdo_async_complete: > > This is another breaking API change, which adds a boolean > "complete" > > parameter to "ecrt_slave_config_create_sdo_request" and > > "ecrt_sdo_request_index". This allows realtime requests to use > > Complete Access; prior to this patch this was only available to the > > non-realtime > API. > > (If this is judged to be *too* breaking, one possible breakage > > reduction > is to > > omit the change to the create function since that is more common than > > use of the index function. However this will require anyone that > > wants to > create > > a Complete Access request to make two API calls specifying the index > > and subindex twice, which seems uglier. Similar for adding a separate > > "ecrt_sdo_request_complete" API, which I also considered.) > > > > As before, note that these patches do not include a change to > > EC_IOCTL_VERSION_MAGIC, but you should change this if you apply any of > > them to reduce the risk of incompatibility (assuming that your app > > checks > the > > versions). > > > > Regards, > > Gavin Lambert > _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
