hi particles,
has anyone had problems with functions using version 7 of the firmware? i have an electron and photon both running versions seven that were behaving fantastically until today - now even basic functions like the blink led example do not work.
It seemed unlikely it would effect two devices and I spent a lot of time trying to find the fault, which I assumed must have been with peripheral hardware. I could not find a problem.
I tried a photon running version 6 of the firmware, thinking I’d somehow damaged both units and behold… everything was fine! I used the particle console calling the argument on and off to control the LED - flashed my (more complex) operational code and again - everything fine on version 6 - but failed every time on 7.
Any ideas? Greatly appreciate any help here .
The very simple test script I ran is as follows:
// -----------------------------------
// Controlling LEDs over the Internet
// -----------------------------------
int led2 = D7;
void setup()
{
pinMode(led2, OUTPUT);
Particle.function("three",threeToggle);
digitalWrite(led2, LOW);
}
void loop()
{
// Nothing to do here
}
int threeToggle(String command) {
if (command=="on") {
digitalWrite(led2,HIGH);
return 1;
}
else if (command=="off") {
digitalWrite(led2,LOW);
return 0;
}
else {
return -1;
}
}
If you are convinced the correlation is with the OS version i.e., 0.6 ok, 0.7 not ok (with identical application firmware), I suggest you monitor your RAM. v0.7 has 10K less available RAM.
Hi @joost . Thanks for your response but surely the very minimal test script would not impact RAM? And my operational script worked for weeks on 0.7 - then suddenly didn’t.
flashed my (more complex) operational code and again - everything fine on version 6 - but failed every time on 7
Is that the minimal script you are refering to or is it the example code you had above? Was not clear to me.
I see you use the String class, always a favorite to cause memory issues but if its just the script above I'd not suspect it right away - of course it may depend on how frequent threeToggle() gets called. Any changes from the outside environment?
Anyway, with limited info, no idea what could be wrong. I'd still monitor RAM though (grin)
Thanks again,
I really appreciate your time at looking at this but I may have jumped to conclusions - hopefully I’ve not wasted too much of your time - or that of the other people who viewed this post.
The story is pretty long - so read on only if you’re interested.
I’ve had some time to extensively look at the problem and it may be I’ve damaged the (particle) hardware. The short story is that it seems the cloud function is working OK - but the outcome it calls (digitalwrite ()) on some pins does not work. The fault is common to 2 particle units I used in the same PCB test rig.
I’m in communication with Rick, one of the Particle guys and I’ll include my explanatory response to him below…if you’re interested.
************After some additional testing I have come to the conclusion that I have somehow damaged the Particle units – although the test PCB I used has been operational and worked fine for many months. While the cloud interface seems to be fine – basic functions like digitalWrite() do not seems to work for some pins.
Let me explain:
I have the photon (and electron) talking to an ATMEL 328p DIL type chip (basically and arduino UNO working at 8Mhz – 3.3volts). The interface to the Photon includes pins D5 and D6 – plus the serial tx / rx.
What I have found is that the Photon (and Electron) are not able to do digitalWrite() on pins D5 or 7 (probably others – though, I tested D6, D3, D4 and A0 and these worked OK).
Weird… hmmm, yes.
This is very confusing as the units were always operated using quality power supplies and in good environments. The onboard PCB regulators are working fine and cannot provide more than 3.3v to the ATMEL chip (so I don’t see how a spike could come through the pins interfacing with the Photon) and the Photon was never exposed to more than 6 volts on VIN. I have tested the PCB extensively and can find no fault but am not brave enough to install my last remaining photon (the one that is running ver 0.6 firmware). I will scrap the PCB and ATMEL chip on suspicion.
What I’d like to do now is establish whether the Particle units are bricked (I hope not) or what to do to “start again” with a clean firmware installation. I hope you can point me at a guide to do that.
Anyway, this is what happened…
To be clear, I used the Particle Console and a custom HTML scrip to test the photon - both failed to light(or extinguish) the LED in the simple script with arguments “on” or “off”. The console responds as expected with return values - so, yes, it returns 1 for on and 0 for off. Should have seen this first up. The power up cycle up to "breathing” is as expected and flashing code seems to go through the expected process with the magenta LED and the web IDE advising successful flash - no problem.
BUT now the problem is that the LED does not respond - so I thought I’d go back to basics. I flashed a “blinky” program and the LED did not respond. I checked for voltage at the pin (7) and also cycled a second pin (D0) and could find no voltage transition – the regulator onboard seems to provide a clean 3.3v so hardware looks OK. I tried several power supplies all regulated and quality brands, including a very reliable computer USB port - same result. I tried some code that had no conditional or timing methods - same result, no LED. I flashed some code that set several pins high in setup() – got some expected highs on pins D6, D3, D4 and A0 – but not on D7 or D5.
So now I’m thinking I’ve damaged the board.
I ran the CLI script you suggested- and attempted to remotely turn on the LED using the CLI using the “particle call XXXXX digitalwrite D7,HIGH” command and it returned
“Function call failed: Function digitalwrite not found”