Does Workbench support Mesh Devices?

[dfichou]

Does the Workbench now support Mesh devices? I am trying to use Workbench on an iMac to flash either my Xenon or Boron devices and I am getting an error in the terminal:

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 2b04:d00e
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08020000, size = 459072
_dfu-util: Last page at 0x0809013f is not writeable
make[1]: *** [program-dfu] Error 74
make: *** [flash-debug] Error 2
The terminal process terminated with exit code: 2

Press any key to close the terminal.

I can build and then flash using the particle command from Terminal, but then I am not sure how to use the debugger, and it is cumbersome to copy the output path of the bin file from the compile to the flash command.

[shanevanj]

have you done a particle update-cli?

[ScruffR]

Can you run particle serial inspect (in Listening Mode) on that device and post the output?
What is your current CLI vesion?

[dfichou]

This was a clean install, but I did the particle update-cli and go “Updating CLI… no plugins to update.”

[nrobinson2000]

Just a quick sanity check: Have you selected your platform and deviceOS version? A lot of the time when I first create a project the platform is set to photon.

[dfichou]

$ particle version
2.2.0

$ particle serial inspect
Could not get inspect device: Serial timed out

Got the same results when the micro usb was plugged into the Xenon or Boron.
I was able to get the Boron into DFU mode and tried again:
$ particle serial inspect
Could not get inspect device: No serial port identified

I only have on board connected to the Mac at one time. And from the command line I can compile and flash:
$ particle flash --usb /Users/dfichou/boron_firmware_1585521745867.bin

Flash success!

[ScruffR]

Can you run particle update -v (in DFU Mode) and then put the device into Listening Mode (blinking blue) again and check particle serial inspect again?

@dfichou

Could not get inspect device: No serial port identified

Are you running Linux or MacOS?

If so you may need to state the port (via the --port switch) you want to connect to.

[dfichou]

That was a big help, yes the device was still set to Photon, but I did not even notice that was a selectable field. Thanks for the screen capture. Now I am blocked at a different place: After hitting the green right arrow to start the debug it appears to have compiled but I have a blocking dialog with " Failed to launch OpenOCD GDB Server: Timeout., with a "Cancel" and "Open launch.json" buttons.

Terminal Output:

Executing task: make -f '/Users/dfichou/.particle/toolchains/buildscripts/1.9.2/Makefile' flash-debug -s <

:::: PUTTING DEVICE INTO DFU MODE

Done.

:::: FLASHING APPLICATION FOR DEBUG

text data bss dec hex filename
752864 2244 80828 835936 cc160 /Users/dfichou/Particle/First/target/1.4.4/boron/First.elf
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util / Tickets

Suffix successfully added to file
Serial device PARTICLE_SERIAL_DEV : not available
Flashing using dfu:
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util / Tickets

Opening DFU capable USB device...
ID 2b04:d00d
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x00030000, size = 755116
Download [=========================] 100% 755116 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state

ONCE YOU ARE FINISHED DEBUGGING REMEMBER TO RUN Particle: Flash application & DeviceOS (local) <

*** FLASHED SUCCESSFULLY ***

Press any key to close the terminal.

I am running on macOS Catalina (10.15.3) and I do have the Nordic tools installed (for other work).

[ScruffR]

@dfichou

I did not even notice that was a selectable field.

That's just a convenience feature to set the target via this "button".
The elaborate (standard) way to do it would be via the respective command

[dfichou]

I was able to do the particle update -v and put the device in Listening Mode and got:
$ particle serial inspect
Platform: 13 - Boron
Modules
Bootloader module #0 - version 501, main location, 49152 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1406, main location, 671744 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
Bootloader module #0 - version 501
Radio stack module #0 - version 202
Radio stack module #0 - version 202, main location, 192512 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS

Yes I am running macOS Catalina 10.15.3

I did an ls /dev/tty* and discovered tty.usbmodem14101, which appears when the board is plugged in. So I tried to add to my launch.json the line “port”: “tty.usbmodem14101”, but that did not work either.

[nrobinson2000]

I think you need to select the right debugger. Open the debug tab, and click the drop-down menu, and select Particle Debugger (argon, boron / bsom, xenon).

[dfichou]

I did that.

I actually removed a configuration that I don’t have from launch.json. So you only see two.

[nrobinson2000]

@dfichou

Failed to launch OpenOCD GDB Server: Timeout

I've seen something similar to this on Linux. There might be a stray openocd process running in the background hogging port 6666.

[ISSUE] Failed to launch OpenOCD GDB Server: Timeout

Furthermore, on Linux there seemed to be a runaway openocd process that was already using port 6666. $ netstat -tulpn | grep 6666 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 127.0.0.1:6666 0.0.0.0:* LISTEN 6374/_openocd Killing the process and then starting the debugger in the properly created Workbench project worked. $ kill -9 6374

On mac you'll probably have to run:

$ sudo lsof -i tcp:6666

If you find the PID of openocd in the PID column you can kill the process with:

$ kill -9 PID

[ScruffR]

Just to make sure:

• you do own and use this HW debugger (or one featured in the linke bellow)
• you have it setup as outlined in this tutorial
• you have a debugging device OS and application flashed

[dfichou]

Yes, I have the Particle debugger, and now I have both the debugger connected and the micro USB connected and I get much further, it can flash (I am guessing through the micro USB) and it seemed to open the debugger yet I could not setup breakpoints. So I tried to debug again and now I am back to " Failed to launch OpenOCD GDB Server: Timeout., but I will work more on this tonight. Thanks all for your help so far, I have something to play with tonight.

[dfichou]

This got me into the debugger! I stopped in setup code and got the device into an unhappy state where it started to flash the led red. But a quick restart and I think I am all set now. I discovered you do have to wait for the device to be fully booted and connected to the network before the setup() or loop() is called, which makes sense now.

[nrobinson2000]

@dfichou

I discovered you do have to wait for the device to be fully booted and connected to the network before the setup() or loop() is called, which makes sense now.

To change that behavior you can use SYSTEM_THREAD(ENABLED);

I'd also recommend using SYSTEM_MODE(SEMI_AUTOMATIC);