Particle Core Serial on 0.4.1 and Ubuntu does not work

Cannot get the Core with latest develop branch build to connect as a valid serial device on linux. The board is fine, as the serial works with the main codebase and I can flash it with fine dfu-util still. This is my only switch to the development branch so I can’t tell you when it started doing this. Output from dmesg:

[17129.387111] usb 6-2: Product: CORE DFU
[17129.387114] usb 6-2: Manufacturer: Spark Devices
[17129.387117] usb 6-2: SerialNumber: ABC123456 (redacted)
[17148.428440] usb 6-2: USB disconnect, device number 32
[17148.668115] usb 6-2: new full-speed USB device number 33 using uhci_hcd
[17148.788113] usb 6-2: device descriptor read/64, error 18
[17149.012039] usb 6-2: device descriptor read/64, error 18
[17149.228154] usb 6-2: new full-speed USB device number 34 using uhci_hcd
[17149.352138] usb 6-2: device descriptor read/64, error 18
[17149.576099] usb 6-2: device descriptor read/64, error 18
[17149.996156] usb 6-2: new full-speed USB device number 35 using uhci_hcd
[17150.404060] usb 6-2: device not accepting address 35, error -32
[17150.516144] usb 6-2: new full-speed USB device number 36 using uhci_hcd
[17150.924079] usb 6-2: device not accepting address 36, error -32
[17150.924167] hub 6-0:1.0: unable to enumerate USB device on port 2

Using a very simple Serial script:

void setup()
void loop() {
    Serial.println("Hello world!");

Thanks for the help!

Thanks for the issue report - we’ll look into it! :smile:

If you could try earlier commits in the develop branch to see if things improve that would be a great help in tracking down the issue. Also please try the feature/hal branch. Thanks!

It works in feature/hal! Working in feature/hal to fix a different problem for now, but I will hopefully get back to this.

Great. That’s good to know. What problem are you working around? I’m interested in all problems in the develop branch, since this will become the release for the core in a few weeks time.


One is dealing with end-user wifi credentialing on my custom app without AUTOMATIC mode. I would like to move away from the main codebase, but I can confirm that a fix hasn’t happened.

Second is debug mode isn’t wanting to flash for develop branch only. I’ll make a separate ticket if I don’t figure it out. For feature/hal it works though.

Oh the joys of working on hardware…Thanks for being upbeat! :slight_smile:

I’m working on it again now. Doing a git bisect.

Is it just me or do like 1/2 of the commits on develop not even build? Is the lack of a pre-commit “builds and all tests pass” on purpose?

are you trying the latest build btw? I fixed an issue with Serial recently that was due to shared state not being declared volatile.

regarding buildability of each commit, we’ve taken to preferring small, readable commits, with incremental changes, over large commits with all changes, which sometimes means there can be intermediate commits that don’t build. It’s rare that we have to build some arbitrary commit, but we read commits often, so this seems like the right tradeoff in this case.

Yep, working with both of those. Problem is not fixed.

Okay, sounds reasonable. I’m not that experienced with version control yet.

Some of the errors are consistent, I might be able to back-insert the changes from HEAD. Is there a good way to do this?

But otherwise, am I going about the bug-finding the right way? (Git bisect; if not building ‘git bisect skip’; if building upload to board -> ‘git bisect good’ or ‘git bisect bad’)

If it helps, here are some “good” commits (ones that build and the serial works):
[c19ad4cc][1] (Feb 3), and [17b25f6d][2] (Mar 11)

And some bad commits: 271a465f (May 22).

A lot of the rest since then don’t build for one reason or another. I am running make clean and git clean -d -x -f in between checkouts which fixed some of the build errors I was having.

Yes, a clean build and clean working copy are necessary, or new files that were present won’t be later deleted, so the working copy is then a mixed state.

Can you try building the latest system firmware with

cd modules/photon/system-part2
make clean all COMPILE_LTO=n program-dfu

I know that this is a clean working copy as I deleted the entire repo and started over :wink:

cd modules/photon/system-part2
make clean all COMPILE_LTO=n program-dfu

arm-none-eabi-g++: fatal error: /usr/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/nano.specs: attempt to rename spec 'link' to already defined spec 'nano_link'
compilation terminated.
make: *** [../../../build/target/system-part2/platform-0-m/system-part2.elf] Error 1

Looking at the error and this dup of it, I have no information other than my g++ version is

arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for ARM Embedded Processors) 4.9.3 20150303 (release) [ARM/embedded-4_9-branch revision 221220]

Also, I’m using a Particle Core, not a Photon. Is the path correct?

Sorry my bad, thinking you were on a Photon for a second.

Then please run that command from the main directory.

Not working still from both main and above it. It is definitely building though!

Oddly, turning on DEBUG_BUILD=y makes the serial port work on the latest commits!

sudo make clean all COMPILE_LTO=n DEBUG_BUILD=y program-dfu works
Removing COMPILE_LTO flag makes it not work.
sudo make clean all DEBUG_BUILD=y program-dfu does not work

Also, compiling and flashing from the online interface works. (serial works fine)

Had exactly the same issue on a mac. Building with the COMPILE_LTO flag solved it for me. I was also using latest develop branch.

1 Like

Howdy! I’m pleased to say there’s a fix for this in the develop branch. Please try it out and let me know!

1 Like

Awesome, thanks Matt! The fix worked! (no COMPILE_LTO flag needed)

sudo make clean all PLATFORM=core program-dfu