Local ARM Build for P1 Not Creating Usable Binary


#1

I’m currently building a product based on the P1 module. While I wait for final layout and assembly of my prototypes I wanted to continue my firmware dev on a P1 development board so I purchased a Redboard from Sparkfun. In building firmware I assumed I should use the PLATFORM=P1 argument but when I do that I get errors trying to flash the resulting binary over DFU that says:

Error writing firmware...Incorrect platform id (expected 8, parsed 6), use --force to override

I also realized the dev board is called the Photon Redboard. Why wouldn’t I program this as a P1 and is Photon really the target I should choose? If so, when would I ever use the P1 target option?


#2

Looking at the source code for Particle CLI it looks like I may have been reading the message backward. It seems like from the DFU connection it’s expecting P1 to be the target but it’s parsing PHOTON out of my firmware binary even though I’m building with:

make all PLATFORM=P1

#3

Here is part of the output from the makefile running with the platform set to P1. Wondering why the platform name doesn’t change.

arm-none-eabi-g++ -DSTM32_DEVICE -DSTM32F2XX -DPLATFORM_THREADING=1 -DPLATFORM_ID=8 -DPLATFORM_NAME=photon

The ID is set to 8 so not sure how it’s parsing 6 from the binary.


#4

To make this even more interesting the particle compile p1 creates a binary that can be programmed over DFU so it would appear there is something wrong with the make files for building P1 binaries locally. Can anyone confirm that a local gnu arm build for the P1 module works? I’m currently using the following version of the arm toolset:

# arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for ARM Embedded Processors) 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589]

#5

Just for fun I git pull'd my local particle firmware repo. I was on the stable branch which, since my last pull, took me from a 0.6 version up to 0.7.0. Now when I run make all PLATFORM=P1 I get a proper binary as confirmed by running the binary-version-reader js sample code I found by digging through the CLI source. I’m also able to successfully program the P1 on the Photon Redboard.

How is this so, you ask? I have no idea and frankly don’t feel like spending the time digging through all the file changes that happened in my latest pull to figure it out. I’m able to build P1 binaries and use them to program my board so I’m calling this one resolved. If you see this issue, the best I can recommend is getting your firmware source to 0.7.0 as of this posting. I guess I’ll be force-upgraded to that version so I can keep moving forward.


#6

If you’re looking for a tool to expedite local Particle development for macOS and Linux, I would highly recommend trying po, a solution I’ve been maintaining for over 2 years that serves many Particle users. It can bootstrap any Mac or Linux machine into a local Particle development ready machine in around 10 minutes.

It’s open source and written in bash. The source can be found on GitHub.

You can install it with:

$ bash <(curl -sL get.po-util.com)

You can join the po community on gitter for support.


EDIT:

To create and build a P1 project with po you can do:

$ po P1 init someProject
$ cd someProject
$ po P1 build

po even supports automatic dfu-util flashing, putting the P1 into DFU mode automatically whenever you use:

$ po P1 flash

#7

Hey Nathan, thanks for the suggestion. I’ve used po before and love the work you’ve done there. There were a few things that caused me to go the Docker route instead for my project. I also wanted to use a different project structure which didn’t seem possible with po-util. Keep up the awesome work on the project and thanks again for the suggestion.


#8

Thanks for the feedback. I added support for using po within Docker recently. I’ve been trying to make po compatible with the “official” particle-cli / Dev structure but there are few more steps required than just a build.mk.


#9

Didn’t realize you were working on Docker integration. That’s good to know and awesome. I rolled my own Docker image because I didn’t like how the “official” one had the source code built in. At least the last time I checked. I like to mount it in so I can iterate on it if I need to or quickly check out different branches to test features without having to pull a completely different image. If I can find some time I’ll swing back around and check out the Docker integration stuff you’ve done. I love the idea of using Docker as a build env.