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 <f...@igh.de> Sent: Tuesday, 22 September 2020 10:24 pm To: Graeme Foot <graeme.f...@touchcut.com> Cc: etherlab-dev@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
0002-retry-dc-register.patch
Description: 0002-retry-dc-register.patch
0001-slave-scan-retry.patch
Description: 0001-slave-scan-retry.patch
-- Etherlab-dev mailing list Etherlab-dev@etherlab.org http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-dev
