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?
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
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.
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]
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.
1 Like
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
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.
1 Like
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.
1 Like
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.
1 Like
Sorry to bring this thread back from the dead but I stumbled upon your youtube video about po-util and docker today. How did making a Docker image with Alpine Linux to build Particle firmware go?
1 Like
Hey @nrobinson2000. I bailed on the docker image based on Alpine. Was having a hard time getting the tools to work in the environment with musl. Ultimately I needed it to work on making a product so I took the short route and ended up building an image based on FROM debian. I’d love to revisit it at some point but I’m still in the depths of trying to get my product released. Happy to answer any questions you have if I’m able.
1 Like
What was the project structure you were using? I’ll be making some updates to po-util for Mesh support so I might look into adding support for different structures.
Po-util is not just for compiling firmware but also for flashing firmware and managing devices. I’ve gotten po-util to compile firmware in docker but not flash.
I’ve had a discussion with @warriorofwire about using po-util in docker over on the po-util Gitter room.
I have a src folder with my main application header and source and a lib folder at the same level as src with all my custom and 3rd party libraries. At that top level I also have a tests folder which is excluded from the firmware build and is build by CMake as a separate binary that runs Catch tests against my libraries and project.
Getting po-util to flash from inside Docker will take a bit of hoop jumping on Mac at least until they (if they) change the isolation pattern. I have full debug working via a container. Did a writeup of it you can find at https://www.kevinsidwar.com/iot/2018/3/1/local-particle-build-and-debug-through-docker-on-mac
Essentially you have to run Docker “less natively” to expose access to the USB port so you can do things like flash and debug. Hopefully that helps. Let me know if you need anything else.
1 Like
Nice setup.
I never really intended to run po-util inside docker because it does such at good job of setting up the environment on Mac and Linux. Part of po-util uses a Docker container to build firmware for Raspberry Pi.
I understand that po-util is not perfect for everyone but it works flawlessly for me and anyone I introduce to Particle.
Absolutely. I’d recommend po-util to anyone who asked. Perfect solution for the majority of users.
1 Like
