Boron Unsuccessful Flashing after multiple OTA flashing tests

I am experiencing similar circumstances but with a boron. Could you help us, we are relatively new and learning on the go. We are doing flashes OTA, they worked a couple of weeks ago. Once one boron started to exhibit the issues we moved to another boron that successfully flashed for a while but then did the same thing.

Hi ScruffR,

I am experiencing similar circumstances but with a boron. Could you help us, we are relatively new and learning on the go. We are doing flashes OTA, they worked a couple of weeks ago. Once one boron started to exhibit the issues we moved to another boron that successfully flashed for a while but then did the same thing. We have remote capability too.

Have you worked your way down from the top of this thread?
You should try all the suggestions given and answer the questions asked.

This is the common way to approach situations as yours - especially with such a thin error description :wink:

But your description sounds slightly different to what I expect to be the problem here so I suggest you open your own thread to avoid hijacking this thread.

Thank you ScruffR. We did get through your recommended tests except our health test has failed diagnostic test but we don’t see specific failures provided. We did make sure we are targeting the correct device. I have started a new thread/topic titled Boron Unsuccessful Flashing after multiple OTA flashing tests

I have transfered the other posts over here now.

So we’ll recap

  • are you using Web IDE?
  • what does the RGB LED do?
  • have you tried Safe Mode?
  • what happens when flashing while in Safe Mode?
  • what do you see in console?
  • what code is running on the device when the OTA update fails?
  • what code are you trying to flash?
  • can you flash OTA after you had put Tinker back on via USB (particle flash --usb tinker -v)?
  • what does particle serial inspect report?

We are using the web IDE.
The LED remains breathing cyan when flashing fails.
Safe mode tells us it is healthy.
We just ran the flash in safe mode and it was successful. What does that mean?

When we just did the successful flash in safe mode the LED went back to breathing cyan

This mostly happens when your code on the device is hogging the controller not allowing for the background tasks to attend to the cloud often enough.
Hence the question about the currently installed firmware.

This is the code we are running when we have the failure

#include <string>
int incomingByte = 0; // for incoming serial data
float value;
String RLString = "";
void setup() {
    Serial.begin(9600);
    waitFor(Serial.isConnected, 30000);
    Serial.println("Serial Begin");
    Particle.publish("First_publish_in_setup", "first publish from setup");
}
void loop() {
     while (Serial.available() > 0) {               //Device responded
        char inchar = (char)Serial.read();         //get the char we just received
        Serial.write(inchar);
        Particle.publish("Second_publish_in_loop", "second publish in loop");
        if (inchar == '\r') {                       //if the incoming character is a <CR> end of message
            Serial.println("\n\rFound a CR!");
            value = RLString.toFloat();        
             Particle.publish("Third_publish_in_loop", "Third publish in loop");
            Particle.publish("Signal_From_Model", String(value));             //Publish
            RLString = "";
        } 
        else {
          RLString += inchar;                   //add the char to the var called RLString
        }
    }
    Serial.printlnf("\n\rReceived string so far: '%s'", (const char*)RLString);
}

Device OS is 1.4.0

@nn13, from the looks of your code, you are going to quickly exceed the Publish limit of 1 per second if a lot of characters are received on Serial. This will cause the Particle Cloud to block the Publishes for increasing periods of seconds until the Publishes stop for a period of time and keep within the publish limit. Also, it seems you print Received string so far... as fast as loop() runs instead of at fixed intervals like once per second. I suspect both of these conditions will lead to the problems you see.

What exactly are you trying to achieve with this code?

1 Like

@peekay123 We are trying to send different text based commands to mobile apps that the mobile apps receive and know how to execute on their end. Correct me if I’m wrong but based on what you are saying we can’t send a worded command??

@nn13, your description doesn’t match what you are doing in code. How are you trying to send the text commands to a mobile app - via the Cloud (ie Particle.publish), via BLE?

If you are receiving commands via the Serial port and want to parse and send them to your mobile app, the code is not really doing this. You could look at the command-parser library on the Web IDE.

1 Like

@peekay123 We are trying to do this by having the boron hooked up via usb to a pc and sending via cellular. We have been able to send and receive single characters but have run into issues when converting to string in order to send multiple character. We have been using code that we have found via the community.

@nn13, when you say “cellular” what do you mean exactly? As for “accumulating” a complete command, delimited by a carriage return or linefeed, there are plenty of examples of this in both the Arduino and Particle worlds.

Cellular as in utilizing the cloud to have the commands received via cellular/mobile devices running android and IOS.

Can you provide a particle example or maybe a link?

@peekay123 and @ScruffR Thank you each for helping us out!