Peripherals don't work after OTA (cloud flash)

Firmware Device OS
1

Yet they work fine (device fully recovered) after a local flash of the exact same code..

Specifically the ('supported') Wiznet w5500 ethernet chip on spi1.
Since it's working after local flash highly doubt anything to do with reset, clock, etc. pins or spi mode 0 are the issue... yet we jog the reset pin if detect non-response. Still doesn't work.

Nothing else seems to be an issue; power (USB vs pwr sup on vin pin), plugged vs unplugged ethernet cable, ip addr (client, server), etc. And using new version # in Particle Product on fleet flash, etc.

**What exactly is the difference between a local and cloud flash; does it fully shut off/on the peripherals, such that we'd have to accommodate that in an OTA for proper startup?

2

At first I thought non-cloud (local) libraries might not be packaged up in a cloud flash, but that can't be..

Else, are monolithic vs separate part builds still a thing?
But again, I don't see that affecting peripherals..

And just now we did some 'additional' lines of testing in setup() (like reset / re-initialize spi1) but that didn't work either.

3

What device are you using? The W5500 isn't supported on the Electron.

What version of Device OS?

Are you local flashing in DFU mode? Are you going into it using buttons or by USB request?There shouldn't be any difference between resetting after OTA, which uses System.reset() and resetting by USB request to go into DFU.

My guess, and this is only a guess, is that there's a difference in what state the W5500 is left in. For example, it's doing an SPI transaction when the device resets OTA, but since it's inactive when in DFU, that does not occur. However, the hardware reset line on the W5500 should fix that.

Does removing the power fix the W5500? How are you powering it? 3V3?

4

Sure,
Now unsure what's supported by Electron, but believe we're using the 'supported' lib (NCD Eth Overlay)

Either way, to recap the usual;
OS 3.3.1
w5500 powered by 3.3vdc from pcb
Doing all the spi1 stuff (and the System.reset() after boot)

We even go one step further in setup() on Particle reboot to include stuff like -

void resetW5500() {
    pinMode(W5500_RST_PIN, OUTPUT);
    digitalWrite(W5500_RST_PIN, LOW);   // Pull the reset pin low
    delay(100);                         // Wait 100ms
    digitalWrite(W5500_RST_PIN, HIGH);  // Pull the reset pin high
    delay(100);                         // Wait for W5500 to stabilize
}

Now I was wondering the same myself.. maybe we're not managing reset or CS fully / the best way, but no other thing would explain the local vs cloud flash, right?

5

Oh, I thought you were using the W5500 as the cloud connection, which is not supported on the Electron. Using it with a 3rd-party library is fine.

How are you powering the Electron? USB or VIN? Do you have a battery? Which Electron?

I'm leaning toward a power issue now. The W5500 draws a lot of current at startup and I'm guessing there's a subtle difference in the timing when the device boots. When it's failing I'm guessing the W5500 goes into a brownout state and that's why you can't recover it using its reset line.

As a quick test, I'd try using SYSTEM_MODE(SEMI_AUTOMATIC) and waiting for a second in setup() before calling Particle.connect(). This will prevent the cellular modem from turning on right at boot, which may help if power is the issue.

6

Using VIN out in the field, but when testing in house we normally have both plugged in while local flashing or cloud flashing.

Should we initialize the w5500 chip before calling Particle.connect() ?

or is just a delay to the particle connect itself, then set up the w5500 later?

7

Also something of note is the behavior persist independent of the power source, from what we have found if it is local flashed it powers up and connects ethernet fine and will continue to do that every time it is powered up. If it is cloud flashed then it will always fail to connect to ethernet, even if it is power cycled. Its like the way the code is compiled and ran form the cloud is functionally different some how?

8

I have tried what you suggested

  switch (connectionType)
    {
    case SerialConnection:
        setUpSerial();
        break;
    case EthernetConnection:
        setUpEthernet();
        break;
    default:
        break;
    }
    delay(5000);
    Particle.connect();  // Needed in semi-auto

As well as

 delay(5000);
Particle.connect();  // Needed in semi-auto

with the connection to ether net coming later and neither were succesful, if this is what you were meaning for us to do

9

Well then it's a mystery. I have no idea why it's behaving that way.

1 Like
10

Thanks for input Rick, we'll report back if we find something.

11

@rickkas7 could there possibly be an issue with the fact we downloaded the NCD_Ethernet_Overlay library and made changes to it. When cloud flashing is it possible that its using the original library ? and ignoring our changes to it locally.

12

Hi, cloud flashing will use the original library or not according to the project.properties file.

Cloud compile will build with the ORIGINAL library if you have this:

dependencies.NCD_Ethernet_Overlay=1.0.1

Cloud compile will build with YOUR library if you have this:

#dependencies.NCD_Ethernet_Overlay=1.0.1

So for your changes to take effect you need to comment out or remove the library reference from project.properties.
Cheers,

4 Likes
13

@gusgonnet Thank you! I believe that was it. This has been a huge headache for the last week.

1 Like
14

Righto, sorry even I probably should have pondered more on that, but thanks again!