# Code working on Photon doesn't work for Core

**URL:** <https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300>\
**Category:** Troubleshooting\
**Tags:** photon, core\
**Created:** [June 11, 2019, 9:57pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300 "2019-06-11T21:57:49Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 11, 2019, 9:57pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/1 "2019-06-11T21:57:49Z")

</div>

I have some code compiled on the web IDE which works nicely when flashed on a Photon but doesn’t work on an old Core, in both cases I’m compiling for firmware version 1.1.0.

```auto
// This #include statement was automatically added by the Particle IDE.
#include <elapsedMillis.h>

// This #include statement was automatically added by the Particle IDE.
#include <HttpClient.h>

int count;
int interval;
String id;
String channel;
elapsedMillis elapsed;

void setup() {
    Particle.function("update", update);
    Particle.function("setId", setId);
    Particle.function("setChannel", setChannel);
    Particle.function("setInterval", setInterval);
    Particle.variable("count", count);
    Particle.variable("channel", channel);
    Particle.variable("interval", interval);
    Particle.variable("id", id);
    id = read(20);
    channel = read(0);
    EEPROM.get(70, interval);
    if (interval < 10000) {
        interval = 10000;
    }
    update("start");
}

void loop() {
    if (elapsed > interval) {
        update("auto");
    }
}

HttpClient http;
http_request_t request;
http_response_t response;
http_header_t headers[] = {
    { "Accept" , "*/*"},
    { NULL, NULL } // NOTE: Always terminate headers will NULL
};

int update(String extra) {
    request.hostname = "myhost.example.com";
    request.port = 80;
    request.path = "/counter/" + channel + "/" + id;
    http.get(request, response, headers);
    if (response.status != 200) {
        return -1;
    } else {
        elapsed = 0;
        count = atoi(response.body);
        Particle.publish("counter", extra + " " + channel + ":" + count);
        return count;
    }
}

int setInterval(String val) {
    interval = atoi(val) * 1000;
    EEPROM.put(70, interval);
    return 1;
}

int setId(String val) {
    id = val;
    write(20, val, 50);
    return 1;
}

int setChannel(String val) {
    if (val == "youtube" || val == "twitter") {
        channel = val;
        write(0, val, 20);
        return 1;
    }
    return -1;
}

const int STRING_BUF_SIZE = 64;
void write(int addr, String data, const int max) {
    
	char stringBuf[STRING_BUF_SIZE];

	data.getBytes((unsigned char *)stringBuf, max);
	EEPROM.put(addr, stringBuf);
}

String read(int addr) {
	char stringBuf[STRING_BUF_SIZE];
	
    EEPROM.get(addr, stringBuf);
	stringBuf[sizeof(stringBuf) - 1] = 0; // make sure it's null terminated
	String str(stringBuf);
	return str;
}

```

On the core, from the web console:

- the OS version doesn’t show up
- any attempt to invoke the `setChannel` function fails (returns `-1`)
- any function call seems unable to write to EEPROM
- no event gets published

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [June 12, 2019, 5:24am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/2 "2019-06-12T05:24:31Z")

</div>

Are you sure the code sticks on the Core?  
Do you get a new application hash event in console when you flash the new code and the Core starts the first time?  
You can try flashing via USB `particle flash --usb firmware.bin -v`.  
To download the binary click the ![image](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/5/4/5427ecdfffd6001cd434241322f2432bc7449d64.png) icon next to the project name in Web IDE.  
Before flashing check `particle binary inspect firmware.bin` to make sure the binary is actually meant for the Core.

You are also _always_ writing 64 bytes to EEPROM even if that would overwrite following data.  
`EEPROM.put()` uses the size of the object you pass in to determin the length you want to write, not its contents. Even if the string is only 20 bytes long, the array is 64.  
You may rather want to use this

```cpp
 void write(int addr, String data, const int max) {  
	char stringBuf[max];

	data.getBytes((unsigned char *)stringBuf, max);
	stringBuf[max-1] = '\0'; // may not be needed, but the docs for getBytes() aren't clear on that
	EEPROM.put(addr, stringBuf);
}

```

_(this is also safer since your original code would even accept `max` to be greater than `STRING_BUF_SIZE` which would be fatal)_

> [@rlogiacco](#):
>
> Particle.publish("counter", extra + " " + channel + ":" + count);

You should add a scope (e.g. `PRIVATE`) there.

BTW, when your `setChannel()` call returns -1 that would indicate the incoming `val` string doesn't match your options.  
How about `Serial.println(val)` to see why?

You should add some more of these `Serial.print()` statements in order to get a feeling where your code goes wrong. That would usually be the first step of debugging your code _yourself_.

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 12, 2019, 10:52am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/3 "2019-06-12T10:52:32Z")

</div>

> Do you get a new application hash event in console when you flash the new code and the Core starts the first time?

In console I see 3 events:

- spark/flash/status - started
- spark/flash/status - success
- spark/device/last\_reset - user

> BTW, when your `setChannel()` call returns -1 that would indicate the incoming `val` string doesn’t match your options.  
> How about `Serial.println(val)` to see why?

Did it and what I see on the terminal is some garbage followed by the function name and the provided value... Please note I added the `Serial.println` statement as first in the function, so nothing has messed with the value yet. I also double checked the terminal connection was using the right settings (baudrate and everything).

```auto
}┘ÍbÃQ~Ú[j3¾sj░◆•⎽)⎺V²§šNŒIº[w≤u¶b¿¸µ={µJ·¤
Äπ5œÿÐ5ouA⎻±f
setChannelGtwitter

```

> Before flashing check `particle binary inspect firmware.bin` to make sure the binary is actually meant for the Core.

Output is

```auto
firmware.bin
 CRC is ok (c6769ed6)
 Compiled for core
 This is a monolithic firmware number 0 at version 1102

```

> You can try flashing via USB `particle flash --usb firmware.bin -v` .

Done, but i was pretty sure this didn't change much anyway, here follows the output:

```auto
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 109324
Download [=========================] 100% 109324 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Flash success!

```

> You are also _always_ writing 64 bytes to EEPROM even if that would overwrite following data.  
> `EEPROM.put()` uses the size of the object you pass in to determine the length you want to write, not its contents. Even if the string is only 20 bytes long, the array is 64.

I applied the suggested change, which required an additional cast to `(unsigned char *)` when performing the `put` to avoid a compilation error:

```auto
no matching function for call to 'EEPROMClass::put(int&, char [max])'

```

As expected, this didn't change much as the issue seems to be with the incoming value.

> You should add some more of these `Serial.print()` statements in order to get a feeling where your code goes wrong. That would usually be the first step of debugging your code _yourself_ .

You are totally right and it is my general practice, I was surprised the same code was running nicely on the Photon though...

Is it possible I had to do something special to upgrade the system part of the firmware on my Core other than flashing a new sketch? I remember it was a different, more complex process back in the days... If that's not the case then my conclusion is something is wrong in the 1.0.1 and 1.1.0 firmwares (the two I have tried) with regards to the interpretation of the extra function argument which is probably passed through as a structure containing additional data like the function mane and the device identifier....

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 12, 2019, 10:57am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/4 "2019-06-12T10:57:49Z")

</div>

I’m thinking about what was called “Deep Update” and what concerns me is the fact the _Device OS_ and _Serial Number_ fields in the web console are _Unknown_…

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [June 12, 2019, 11:16am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/5 "2019-06-12T11:16:04Z")

</div>

> [@rlogiacco](#):
>
> Is it possible I had to do something special to upgrade the system part

The Core only has monolithic firmware (device OS and application in _one_ file).

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 12, 2019, 11:21am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/6 "2019-06-12T11:21:21Z")

</div>

I also tried the `particle doctor` procedure, but I still don’t see the firmware version in the console or the wed ide…

Reverting the firmware version down to `0.7.0` though fixed the issue: versions `1.0.0`, `1.0.1` and `1.1.0` did all suffer from this.

I’m pretty sure there should be something wrong in the more recent firmware releases…

The downside though is the HTTP connection now just doesn’t work anymore (possible incompatibility of the `HttpClient` library with firmware version `0.7.0`?)

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [June 12, 2019, 4:31pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/7 "2019-06-12T16:31:35Z")

</div>

Yup, there is a _ **still** _ open issue referencing that

> <https://github.com/particle-iot/device-os/issues/1569>

If you could comment on that issue this might help raise the priority.

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 12, 2019, 5:57pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/8 "2019-06-12T17:57:06Z")

</div>

Comment added, I also tried to search github and found @BDub had already fixed that at some point, or at least tried to do so… Maybe he knows better what’s going on here.

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [June 12, 2019, 8:24pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/9 "2019-06-12T20:24:09Z")

</div>

Please try Device OS 1.2.0-rc.1 or better yet, 1.2.1-rc.2 which also has this fix.  
If you don’t have enough memory for your application on the Core, you can also try downgrading to 0.7.0, 0.6.3, etc… for Core.

> <https://github.com/particle-iot/device-os/pull/1770>

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 12, 2019, 8:53pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/10 "2019-06-12T20:53:38Z")

</div>

Thanks for jumping in @BDub. I already downgraded to `0.7.0`, but the library I’m using (`HttpClient`) doesn’t seem compatible with that old version.

I was hoping Particle would have been willing to maintain a decent level of compatibility for older devices, even if it’s normal certain features couldn’t be kept up to date forever.

I’ll give a try to latest release candidates and provide my feedback.

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 12, 2019, 9:08pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/11 "2019-06-12T21:08:03Z")

</div>

I confirm `1.2.1-rc2` is not suffering from this issue.

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [June 13, 2019, 5:00pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/12 "2019-06-13T17:00:05Z")

</div>

> [@rlogiacco](#):
>
> Thanks for jumping in @BDub. I already downgraded to `0.7.0` , but the library I’m using ( `HttpClient` ) doesn’t seem compatible with that old version.

Here's a case where an older version of HttpClient will likely have to be manually checked out from Github and used. I'm mostly positive HttpClient used to work for the Core in the past.

If you can use the latest 1.2.x firmware though, that works.

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 13, 2019, 8:24pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/13 "2019-06-13T20:24:40Z")

</div>

Weird… firmware `1.2.x` solves the issue with the function call, but the `HttpClient` library still doesn’t work… I’m wondering if a memory overflow is occurring somewhere: as soon as I submit the http call I receive a `-1` response, but this was exactly the same behaviour I was experiencing with `0.7.0`… so that makes me think…

To factor out my potential dumbness I went back and pushed the exact same code to the Photon running firmware `1.1.0` and it worked… then I upgraded the photon to `1.2.1-rc2` and…It worked flawlessly.

I know, you are not the library author and you don’t have enough info to pinpoint the issue here, I just wanted to report what I’m experiencing in case someone else follows my same steps.

For completenes, here the code I’m uploading:

```auto
// This #include statement was automatically added by the Particle IDE.
#include <elapsedMillis.h>

// This #include statement was automatically added by the Particle IDE.
#include <HttpClient.h>

int count;
int interval;
String id;
String channel;
elapsedMillis elapsed;

void setup() {
    //Serial.begin(9600);
    Particle.function("update", update);
    Particle.function("setId", setId);
    Particle.function("setChannel", setChannel);
    Particle.function("setInterval", setInterval);
    Particle.variable("count", count);
    Particle.variable("channel", channel);
    Particle.variable("interval", interval);
    Particle.variable("id", id);
    channel = read(0);
    id = read(20);
    EEPROM.get(70, interval);
    if (interval < 10000) {
        interval = 10000;
    }
    update("start");
}

void loop() {
    if (elapsed > interval) {
        update("auto");
    }
}

HttpClient http;
http_request_t request;
http_response_t response;
http_header_t headers[] = {
    { "Accept" , "*/*"},
    { NULL, NULL } // NOTE: Always terminate headers with NULL
};

LEDStatus statusOk(RGB_COLOR_GREEN, LED_PATTERN_FADE);
LEDStatus statusRun(RGB_COLOR_BLUE, LED_PATTERN_FADE);
LEDStatus statusErr(RGB_COLOR_RED, LED_PATTERN_FADE);

int update(String extra) {
    elapsed = 0;
    statusRun.setActive();
    //Serial.print("updating...");
    request.hostname = "myserver.example.com";
    request.port = 80;
    request.path = "/counter/" + channel + "/" + id;
    http.get(request, response, headers);
    if (response.status == 200) {
        statusOk.setActive();
        count = atoi(response.body);
        Particle.publish("counter", channel + ":" + count + (extra.length() > 0 ? " - " + extra : ""));
    } else {
        statusErr.setActive();
    }
    return response.status;
}

int setInterval(String val) {
    //Serial.println(val);
    interval = atoi(val) * 1000;
    EEPROM.put(70, interval);
    return 1;
}

int setId(String val) {
    //Serial.println(val);
    id = val;
    write(20, val, 50);
    return 1;
}

int setChannel(String val) {
    //Serial.println(val);
    if (val.compareTo("youtube") == 0 || val.compareTo("twitter") == 0) {
        channel = val;
        write(0, val, 20);
        return 1;
    }
    return -1;
}

void write(int addr, String data, const int max) {
	char stringBuf[max];

	data.getBytes((unsigned char *)stringBuf, max);
	stringBuf[max - 1] = '\0'; // make sure it's null terminated
	EEPROM.put(addr, (unsigned char *)stringBuf);
}

const int STRING_BUF_SIZE = 64;
String read(int addr) {
	char stringBuf[STRING_BUF_SIZE];
	
    EEPROM.get(addr, stringBuf);
	stringBuf[sizeof(stringBuf) - 1] = 0; // make sure it's null terminated
	return String(stringBuf);
}

```

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 13, 2019, 8:42pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/14 "2019-06-13T20:42:51Z")

</div>

I might have some more info to add: the part reading/writing the variables from EEPROM fails to work on the Core, looks like after setting them and power cycling the Core both variables get back a weird value of `�M`… I can call the setters functions which apparently correctly set the variables, but they are messed up after power cycle.

I went back to firmware `0.7.0` and after setting and power cycling the variables got again to a weird value, but different: `channel` is `HL`, while `id` has value `@L`: am I reading/writing into program area or is some even weirder issue I’m unable to recognize?

Sorry lads, I just wanted to put my old cores (2) to use into a project…

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [June 15, 2019, 4:19am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/15 "2019-06-15T04:19:54Z")

</div>

Re: EEPROM not working… Well that’s no good! So for Core, HttpClient works on 0.7.0, but EEPROM doesn’t? Does your EEPROM code work on Photon? I wonder if it’s an EEPROM issue, or a String \<-\> char array issue? I don’t normally use .getBytes() so I’m not familiar with it. With the limited resources on the Core, I think you’d be better off just declaring a static global char array to use with EEPROM and not copying back and fourth between String and char arrays. That said you have to use String with Particle.function() arguments.

Did you know on Strings you can get the C string returned like this?

```
String val = "world";
Serial.printlnf("hello %s", val.c_str());
```

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [June 15, 2019, 10:19am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/16 "2019-06-15T10:19:43Z")

</div>

> [@BDub](#):
>
> That said you have to use String with Particle.function() arguments.

Not entirely true IMO.  
Although undocumented you can also use a function like this as `Particle.function()` callback

```cpp
int fnHandler(const char* arg);

```

Granted, internally the incoming data is of type `String` but implicit casting allows you to catch it as `const char*` for further treatment inside the function.

Also an alternative (and my preferred version)

```cpp
Serial.printlnf("hello %s", (const char*)val);

```

This also doesn't break if you (at some future time) decide to do somthing like

```cpp
//String val = "world"; // uhh, I was told to avoid String, so replace with
char val[64] = "world";

```

The `c_str()` version would barf and need additional attention, but the `(const char*)` version would still be happy with that 😉  
_"Plan ahead so in future you can be lazy and keep maintainance/refactoring work minimal!"_ 🕶

---

<div class="post-metadata">

**Author:** ![BDub](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bdub/32/5137_2.png) [@BDub](https://community.particle.io/u/BDub)\
**Post date:** [June 15, 2019, 11:30am UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/17 "2019-06-15T11:30:31Z")

</div>

Great tips @ScruffR, thanks!

---

<div class="post-metadata">

**Author:** ![rlogiacco](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rlogiacco/32/20725_2.png) [@rlogiacco](https://community.particle.io/u/rlogiacco)\
**Post date:** [June 16, 2019, 9:55pm UTC](https://community.particle.io/t/code-working-on-photon-doesnt-work-for-core/50300/18 "2019-06-16T21:55:04Z")

</div>

I completely removed the part reading the values from EEPROM and went for hardcoding the desired values without joy. I tried to also factor out any potential issue with cloud functions and re-enabled serial output… still no joy.

I tried both `0.7.0` and `1.2.1-rc2` with latest HttpClient but the call to `http.get` fails with a `-1` return code.

The exact same code on Photon works nicely. I believe something inside the library is no more compatible with the Core.