Error when using Makefile (Eclipse) for debugging


#1

Hi all,

My photon is giving me hard faults continuously so I’ve endeavored to install eclipse and try debug the issue. I’ve followed the guide on the particle FAQ and I could build the tinkerbreak firmware and download it onto my photon fine. I get alot of errors during the make saying “git command could not be found” but other than that, it seemed to have worked. I could put in breakpoints and step through the code fine. What I’m trying to do now is try the same process but with a slightly more complicated project. I’ve setup a standard project with my .cpp file in the /src folder and libaries in the /lib folder. I’m using the default makefile:

# Assumption: These variables will be set in the environment
# $(APPDIR) 
# $(FIRMWARE) 
# $(PATH)
# $(PLATFORM)
# $(TARGETBIN)
# Optionally set $(MAKEOPTS) for things like MODULAR=n DEBUG_BUILD=y USE_SWD_JTAG=y

all : $(TARGETBIN)

# Use the wildcard function explicitly, because just using a dependency on .h files will
# fail if the project doesn't contain any .h files. This will work either way.
source := $(wildcard *.cpp) $(wildcard *.h)

$(TARGETBIN) : $(source)
    cd "$(FIRMWARE)/main" && make all PLATFORM=$(PLATFORM) APPDIR="$(APPDIR)" $(MAKEOPTS)

clean :
    cd "$(FIRMWARE)/modules" && make clean all PLATFORM=$(PLATFORM) APPDIR="$(APPDIR)" $(MAKEOPTS)


.PHONY: all clean

It is failing with this error: “build.mk:65: *** “No sources found in C:/Users/name/Particle projects/projectName/src/”. Stop.”

I’m not sure what that means. I have my .cpp file in there? Not sure if I’ll have to add more to the make file to handle the library files either.
Side note: If anyone knows how to resolve the git command not found issue much appreciated!


#2

Do you actually have a directory named “Particle projects” with a space in it? The standard Makefile cannot build firmware if any directory above it contains a space.


#3

@ricckas7 I just realised it is your guide that I am following :smile:
Thanks alot though! It seems to progress further which is great to see. I also think I fixed my git command not recognised issue by adding it to the PATH environment variable.

Unfortunately I am running into an issue which is less related to debugging and more to do with my issues with local compilations. I have a project that compiles perfectly fine if I add the library dependency in the project.properties file but when I delete these dependencies and do a “particle library copy {library-name}” for each library dependency, it comes up with weird issues. The big one right now is that I have copied the ArduinoJson to my lib folder and doing a “particle compile photon” gives me:

In file included from lib/CoreLibrary/src/CoreLibrary.h:32:0,
                 from src/Controller.cpp:7:
lib/ArduinoJson/src/ArduinoJson.h:7:27: fatal error: ArduinoJson.hpp: No such file or directory
compilation terminated.

As you can see I have the ArduinoJson as a dependency for CoreLibrary. I’ve spent a few hours trying to resolve this but to no avail. Just a side note, the CoreLibrary has on relation to the Core device, just a name I chose. The ArduinoJson.hpp file is in that directory. I’m not sure what the problem is :expressionless:


#4

One thing to not first: particle compile does not perform a local compile but cloud compile.

The next thing is a known issue, where the included examples folder and the <libraryName> folder inside the src folder cause problems. But you can simply remove them.

The final point I’ve come across is that CLI can’t handle anything but .ino, .h and .cpp.
In order to circumvent that, you’d need to locate all #include <XXXXX.hpp> statements in the library and change them to #include <XXXXX.cpp> and also rename the corresponding .hpp files.
I know that’s a pain and using .cpp for “template headers” isn’t good practice either, but it at least should make your build work.


I filed an issue with the CLI repo that may help resolve such problems in future


#5

Okay cool, Thanks so much for your help. From that, I’ve managed to fix the compile errors and could get the debug firmware onto my photon. I have resolved my initial problem with a hard fault where a function pointer was not being instantiated within a library. However, there are a few more issues that I’m encoutering.

  1. Now I’m getting a stack overflow issue. This error comes up about 30 seconds after cloud connection. Apologies because I’ve never used Eclipse (or any debugging tool really) so I’m not sure how to tackle the problem. I’ve tried pausing it when the stack overflow happens and the photon begins to blink red, but the stack trace doesn’t go back far enough such that I can see what was happening before.


    In addition to that, when I select the previous calls in the stack I get the following:
    I’m not sure if this is expected.

  2. I’m getting some errors during build but stop prevent me from building and debugging that looks like:


    I don’t know what the repercussion of this error is.

  3. Last of all, if I try to compile with any of the macros like SYSTEM_THREAD(ENABLED), PRODUCT_ID or PRODUCT_VERSION, the build will fail:

<command-line>:0:12: error: expected unqualified-id before numeric constant
c:/users/name/documents/particleprojects/projectname//src/projectname.cpp:1:2: note: in expansion of macro 'PRODUCT_ID'
  PRODUCT_ID(5519);
  ^
c:/users/name/documents/particleprojects/projectname//src/projectname.cpp:2:17: error: expected constructor, destructor, or type conversion before '(' token
  PRODUCT_VERSION(19);
                 ^
c:/users/name/documents/particleprojects/projectname//src/projectname.cpp:3:15: error: expected constructor, destructor, or type conversion before '(' token
  SYSTEM_THREAD(ENABLED);

Any help is greatly appreciated! Thank you for all the help so far.


#6

Are you including Particle.h or application.h after the PRODUCT_XXX() macros?
Can you post the top portion of your main project file?

With stackoverflow errors you may be initialising too many/big local variables or if you are running a function on any other thread than application thread (e.g. Software Timers), the stack might be too small.


#7

Heres the top of my code:

PRODUCT_ID(5501);
PRODUCT_VERSION(20);
SYSTEM_THREAD(ENABLED);

#include "Particle.h"
#include "application.h"
#include <ModbusMaster.h>
#include "coreLibrary.h"
#include <google-maps-device-locator.h>
#include "ArduinoJson"

#define ON      0xFF
#define OFF     0x00

char* REPORT = "Report";
char* RESPONSE = "Response";

int modbusVersion;
int boardTemperature = 0;
int InputReg[10], HoldReg[10], CoilStatus[10];
int coil, setTemp, ambientTemperature;
char *mode, *fan, *swing;

const int blueLED = D2;
const int greenLED = D3;
const int redLED = D4;
const int modbusEnable = D5;
const int TEMPPIN = A0;

int wifi = WiFi.RSSI();
int status = 0;
int disconnectCounter = 0;
int disconnectedFlag = false;
boolean updatePendingFlag = false;

Timer timer1(PUBDELAY, timedEventPublish);
Timer timer2(300000, disconnected);
//Timer modbusCheckTimer(MODBUSCHECKDELAY, modbusLoop);

mcpSensor temperatureSensor(TEMPPIN, MCP9700);
symbiot symbiotMethods;
GoogleMapsDeviceLocator locator;
Modbus *modbus;

I have tried adding particle.h and application.h but still gives the error.

With respect to stack overflow, it may be possible that I’m declaring too many global variables. Additionally, something I changed recently was that I added a purely virtual base class with 2 subclasses (Modbus). I also do have 3 timers but the modbus timer has been commented out for now. Within timer1, it will construct a json and publish it every minute. In terms of stack/memory, I’m not sure how that may contribute to a stack overflow problem.

@rickkas7 Specifically with eclipse, is there anything I can do with the debugger that would help me narrow down the problem?


#8

As ScruffR pointed out, you have the order wrong. You must include Particle.h before PRODUCT_ID, as the PRODUCT_ID macro is defined in files included by Particle.h.

#include "Particle.h"

PRODUCT_ID(5501);
PRODUCT_VERSION(20);
SYSTEM_THREAD(ENABLED);

#9

application.h and Particle.h are meant mutually exclusive, or rather the latter has superseded the former.

Do I sense doubt? Rest assured, it can contribute.
How are you constructing the JSON? ArduinoJson can be quite heavy on stack.
The stack for the Software Timer’s thread is considerable smaller than the stack for the application firmware - that’s why constructing a local variable in the Software Timer callback may cause a stackoverflow which wouldn’t happen when the same function was run on the application thread.
Also calling mulitple nested functions (call depth) on a thread with limited stack size may lead to stack overflow much quicker than on the application thread.


#10

@rickkas7 Ah yes I see. Sorry, I didn’t realise ScruffR was suggesting to put the #include Particle.h before the macros. That seemed to have solved that issue :smile: Continuing from that though, it seems like the debugger only shows one thread and my photon will just breathe white while the debugger is running. Is this behaviour intended? Or perhaps I didn’t setup some tools property or something.

@ScruffR I think you’re right! I managed to narrow it down a bit. Here is my software timer callback:

void eventPublish(char *eventName){
    if(Particle.connected()){
        char pubBuffer[150];
        DynamicJsonBuffer jsonBuffer;
        JsonObject& root1 = jsonBuffer.createObject();
        
        root1["var1"] = version;
        root1["var2"] = product;
        root1["var3"] = wifiStrength;
        root1["var4"] = tem;
        root1.printTo(pubBuffer, sizeof(pubBuffer));
        Particle.publish(eventName, pubBuffer, 60, PRIVATE);
    }
}

For some reason, the Particle.publish() at the end of my software timer call is causing the stack overflow. If I comment out that line, it seems to run fine. Although I don’t think thats the root of the issue. I think it has to do with the pubBuffer array. At the current value (150) it would cause a stack overflow but reducing it to 100 seems to run okay. I have other projects with the same concept of a software timed Publish and a pubBuffer of sizes up to 255 which seem to work fine. What would be the best way that you suggest to increase the available stack size? I could delete other timers, trim down the number of global variables, convert int’s that dont need to be that large to bytes. Sorry my memory management knowledge is not up to par.


#11

The number of timers is irrelevant for that issue, since the individual timer functions are called one-by-on so their individual stack impact does not add up.
Global variables also don’t impact the stack.
Reducing individual int to byte does also not make any difference since this 32bit controller will always align individual variables at 4-byte boundaries.
It’s the thread that owns the stack and hence you’d need to increase the stack size for the timer thread to allow bigger functions to run, but I’m unaware of that API being exposed.

One thing you can do is to promote your pubBuffer to a global variable which can be shared among all timer callbacks since these are guaranteed to not interfer with eachother.


#12

excellent idea! Everything seems to be running okay for now. Thanks everyone for the help. I’ll report back if there are any more issues.