That’s probably my problem? I cannot see any trace of myProject.ino in the above output. This is the file that is my entry-point and that links to all the others.
Did I miss something? Do I need to call this file something specific? Or do I have to specify what file has the entry-point?
@jenschr, when compiling locally (local toolchain), the compiler won’t “see” an .ino file. You need to rename it to .cpp!
Oh my… You’d almost think that this was so important that you’d mention it in https://github.com/spark/firmware/blob/develop/docs/gettingstarted.md or any of the other “how to build locally” guides by Particle?
But Thanks a lot @peekay123! I now get a load of error messages (since the local build does not work with the Particle project structure) but those I should be able to handle 
One thing though - how does it figure out what .cpp file is the entry-point?
Added a pull request to the readme.md now with the two most important things that stumped me when compiling locally.
Now I just need to understand how to dig deeper into this. I've found this to be a brilliant command:
arm-none-eabi-nm -C -S --size-sort ../myOut/coffeeroaster2.elf
This lists all the methods and how much space they take up in memory. It's a great tool to locate what is taking up RAM and where you could save/optimise.
Any pointers to good articles on analysing memory from a Particle standpoint @peekay123?
@jenschr, this nugget is great as well. Feed it any arm gcc .map file and it produces a memory usage analysis.
That's brilliant! Looking at other threads, it's very confusing how much memory you ACTUALLY have (since some of these threads go back to the CORE). There is however an official link that points to the memory output from the Web IDE and this claims that the Photon has:
110592 bytes for program
20480 bytes for RAM
In my case it should mean that since I get this output from compile:
text data bss dec hex filename
107468 2124 12484 122076 1dcdc /workspace/target/workspace.elf
The text & data columns adds up to the amount of Flash used (out of 110592 available):
107468 + 2124 = 109592 (99% Flash used)
The data + bss columns adds up to the amount of RAM used (out of 20480 available):
2124 + 12484 = 14608 (71% RAM used)
That would explain some interesting behavior in my app this week? 
Time to start using that extra 1Mb of storage in the P1 modules!
@jenschr, the available memory thing is an ongoing beef I have with Particle. They still haven’t fix that. The Photon has near about 128KB of user flash and at least 60KB of RAM (if not 80KB). The numbers given were for the old Core which had 128KB - bootloader of flash and 20KB of RAM.
Right. And the P1 has the exact same specs + that extra Flash chip, right?
Some days ago I decapped a P1 and had a look inside. The P1 Flash Memory chip is called MX25L8006e and it’s from the company Macronix. There’s good documentation on their site and I got that added to the P1 datasheet so others should now find that info more easily. It works right out of the box, so I should be able to offload several things into this memory.
As you may know, @cermak has completed my initial attempts at porting WolfSSL and I have a colleague (more skilled than I am) that is working on a complete AWS IoT setup with TLS 1.2 taking it the last steps. It is however more critical than ever that we get to know the numbers for this as we’re spending 118Kb Flash already (Full TLS stack from WolfSSL + MQTT client). I’ve asked for help in a different thread, but thought I’d mention it here as well in case you had som new details.
the flashee library works with the external memory on the P1, plus you can read/write to it using DFU via the -a 2 flag.
Ohhh… That could be very useful @mdma! Do you have a link to an example of how I could write to the flash in DFU mode?
