String(int) causing SOS safe mode

Hi Community,
For one of my projects I am currently working on requires an integer to be converted to a string. I am working with a Particle electron on the Particle Web IDE.
My lines of code
int wireVal = 0;
Serial.print("wireVal is: “+ String(wireVal)+ " gbye”); // this crashes firmware

crashes firmware, giving a red SOS led, entering safe mode. I have also tried converting wireVal to a string outside the print statement but was unsucessful.
I have used this same syntax on an Arduino but am unsure why this will not work on an Electron. Any help is appreciated. Thanks.

Have you considered not constructing a String from wireVal? You could use the following to just print out wireVal:

Serial.printlnf("wireVal is: %d gbye", wireVal);

Could you possibly share more of your code to help provide some more context? If constructing a String is crashing the firmware there may be a memory-related issue somewhere else in your code.

Also, which device OS version are you targeting?

Hi NRobinson,
my code:

#include <Wire.h>
int wireVal = 0;
int led = D7;
String incomingString= "";

void setup() {
    pinMode(led, OUTPUT);

void loop() {
    digitalWrite(led, wireVal);
    //Serial.println(wireVal); //added august

void receiveData (int byteCount) {
    while (0 < Wire.available()) {
    wireVal =;
    //Serial.println("wireVal is: "+ String(wireVal));
    Serial.printlnf("wireVal is: %d gbye", wireVal);

your print statement also doesnt yied results… my output to putty is completely blank… I am running win8.1 with version on electron device os 1.2.1 Does my error have to do with an object in c? from this post?


I haven’t tested your code yet, but I think I have an idea why creating a String was crashing the firmware. Because the Wire.onReceive() handler operates atomically, I would guess that constructing objects like Strings isn’t allowed in that scope.

I would suggest creating a global byte array that you would use in receiveData() to iteratively store the bytes received from the I2C master, keeping the receiveData() handler as tight as possible.

In loop(), I would suggest doing any additional necessary processing of the array and printing it out to the serial console if the contents of the array changed since the last call of loop().

Could you possibly elaborate on your hardware setup? I assume the Electron running this sketch is connected to an I2C master that is sending data to it? If not, I wouldn’t be surprised if you’re not seeing any reports to your serial monitor.

1 Like

I’d rather put the Serial.print() statement out of the onReceive() callback, just as I wouldn’t put a Serial.print() statement into an interrupt handler.


My hardware setup is in this post, with picture from June 8.

Are you saying move the Serial.print into the setup right after onReceive()? Not quite sure what you are suggesting…

No, that wouldn’t do anything. onReceive() hooks up a callback functino which will be called each time the interface detects incoming data, putting a single Serial.print() statement in setup - where it only gets called once - would only print once, and probably nothing since there wasn’t any data yet.

What I’d rather do is creating a global char array (or other suitable type depending on your expected data) and feed the incoming data into that and have loop() check whether new data has arrived there and if so, print that.