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
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!
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.
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!
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’)
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
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?
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)