I also cannot find much information on what this does
STARTUP(System.enableFeature(FEATURE_ETHERNET_DETECTION));
We are getting zero support from Particle despite speaking to their top customer engagement guy, sending them hardware and being an enterprise customer.
Does anyone have a good understanding of these SPI issues and how to circumvent?
From what we see our lock ups occur when there is a network connectivity issue. We can run for days with no problem then bang - offline. Removing EEPROM writes has alleviated the problem but we cannot avoid Ethernet for some customers
We are running with SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);
The Ethernet/SPI and EEPROM are two separate issues.
The Ethernet/SPI issue is because SPI transactions use a mutex to protect against different threads simultaneously using the SPI bus. However, prior to the fix in PR 1879, there were two separate mutexes, one in Device OS itself, and one in the user part (Wiring). This did not have the desired effect of preventing simultaneous access when the system itself was using SPI, which is the case with the Ethernet FeatherWing. Once that PR is merged, it should fix the problem, as long as the user code also uses SPI transactions.
The EEPROM issue is separate. It’s now believed to be a bug in the nRF52 SDK, see the last comment in issue 1832.
In order to determine if the Ethernet FeatherWing is installed, Device OS needs to probe for it. This uses SPI, as well as pins D3, D4, and D5. Since this could adversely affect any circuit that uses those pins for GPIO, the default is to not probe for Ethernet.
It can be enabled by using the FEATURE_ETHERNET_DETECTION feature flag. It is also enabled by checking the Use with Ethernet checkbox during setup using the mobile apps. The setting is saved in persistent configuration so you only need to set it once.
I am curious about your use of SYSTEM_MODE, why use SEMI_AUTOMATIC with Ethernet?
As a work around for the Ethernet lockup and until the PR is merged, I have a timed test for Particle.connected() and if this is false for a period I then call System.reset(); This isn’t elegant but does keep things running.
You could (as I have done) consider using FRAM instead of EEPROM - I appreciate more cost! In my case I also need to have a Publish buffer because of the uncertainty and also to rate limit - that gets held on FRAM.
We are now in contact with Kenneth De Spiegeleire to try and get insight on what other lurking issues in the Particle platform will cause us issues. We like to find out about the landmines without stepping on them.
In reply.
Why would I not use SEMI_AUTOMATIC and Ethernet? Is there any documentation/errata stating I should not?
Thanks for the suggestion of the reset. I have put something in along the same lines. This interrupts the customer charging their EV so not ideal as you say.
We could have considered using FRAM instead of EEPROM if
a) Particle published details of it’s known issues of EEPROM clearly.
b) We had not got 1000+ units hanging on customers’ walls or in the factory.
My frustration is at the organisation. Why on earth would Particle not warn customers about the device having a unusable SPI bus when it is used in conjunction with Ethernet? This issue has been open for months and I told the support guys about our connectivity problems about 6 weeks ago.
I asked about Ethernet and SYSTEM_MODE because I started off with SEMI_AUTOMATIC and then realised there was no benefit over the default AUTOMATIC. I wondered if you were using it in case of WiFi and if the device was not Ethernet connected.
Our evaluation since the launch of Gen3 and Argon was that we couldn’t risk introducing it in place of the Photon for just having the benefit of BLE and Ethernet. I have had some development products ticking along but none have got to the stage of being installed with customers because of these blockers.
Hi
Sorry to bring this up again but I am trying to prepare for Jan 1st 21 and the end of support for Xenon. Finding Argon cloud connectivity unreliable I have paired a Xenon with Featherwing Ethernet and set it as a gateway for a mesh network. So far so good, works well. However I would like to use the SPI to drive a RFM12B. Is this possible with Featherwing Ethernet SPI? Simple question begging a complex answer
Cheers
Yes, you can use the same SPI bus as the FeatherWing, with some caveats:
Be sure to use a recent version of Device OS like 1.4.4 or 1.5.2. Older versions did not support SPI concurrently between the system and user parts.
You MUST use SPI.beginTransaction() and SPI.endTransaction() around your code that uses SPI. This is what prevents the system and user parts from using the SPI bus at the same time.
Make sure you never call SPI.beginTransaction() within a SINGLE_THREADED_BLOCK or with interrupts disabled as it will likely deadlock the system (eventually).
Make sure you don’t use one of the Ethernet reserved pins (D3, D4, D5) as your CS pin.
