[Etherlab-dev] Improved debugging and behavior on sick SII contents

[Graeme Foot]

Hi Florian,

I've attached two patch files rebased to the default branch.  I haven't built them so hopefully I got them correct.  The second patch is the most important.  It reorders the state machine from:
  Base --> [ DCCap ] --> DataLink --> SII
To:
  Base --> DataLink --> [ DCCap ] --> SII

Where the DataLink state will block until the EEPROM read is complete (with a 500ms timeout).

The first patch may not be required but it retries getting the SII if there are any errors which could happen if the comms are a little unstable after a hot plug.  It also provides a quick sanity check on the vendor_id and product_code.

The patches are also available at:
https://1drv.ms/u/s!AoLeUQXl-H0MiSiDmBK-pHX5bxTB?e=quRDYQ
https://1drv.ms/u/s!AoLeUQXl-H0MiSnV6f7xJeddqgxQ?e=279l5e


Regards,
Graeme.


-----Original Message-----
From: Florian Pose <fp at igh.de> 
Sent: Tuesday, 22 September 2020 10:24 pm
To: Graeme Foot <Graeme.Foot at touchcut.com>
Cc: etherlab-dev at etherlab.org
Subject: Re: Improved debugging and behavior on sick SII contents

Hi, Graeme,

On Mon, Sep 21, 2020 at 09:40:37PM +0000, Graeme Foot wrote:
> I see you checked in some extra debugging on SII content a couple of 
> weeks ago.  Have you identified slaves with consistent SII issues, or 
> are they intermittent?  If they are intermittent then it may be due to 
> the master reading the SII contents before the slave has completed 
> finished reading it in from the EEPROM, so the master ends up getting garbage / uninitialized values.

the reason was, that we started developing some slaves and connected some uninitialized Trinamic slaves that contained only ones in the SII.
That made the master think that the mailbox sizes were 64k, which lead to some problems. :-)

But we never came across such things with regular slaves.

> If it’s intermittent, I wrote a patch for Gavin’s patchset which may 
> help.  The patch reorders the fsm_slave_scan states so that the 
> datalink states (which read register 0x0110) are run before checking 
> the dc registers (which may also be initialised from the EEPROM).  
> This state now blocks until bit 0 is set (PDI operation/EEPROM loaded bit) and error's out if there is a timeout.

Good idea, if that helps for those cases, I'd like to merge it. Can you send me a link to a PR / patch?

--
Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-retry-dc-register.patch
Type: application/octet-stream
Size: 5487 bytes
Desc: 0002-retry-dc-register.patch
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200922/ee4afc2f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-slave-scan-retry.patch
Type: application/octet-stream
Size: 7110 bytes
Desc: 0001-slave-scan-retry.patch
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200922/ee4afc2f/attachment-0001.obj>