Stuck in DFU mode attempting to debug Electron

Developer Tools Particle Workbench
1

Grabbed the new Jan 31, 2019 release of Workbench today. I’m running on a U260 electron device connected to the new particle debugger / openocd hardware and also via USB. I start by putting the device in DFU / flashing yellow mode.

Build / Flash appear to work just fine. Once the flash is complete, VSCode appears to be connected and paused, and the Electron’s RGB LED is off. When I hit “Continue” in VSCode, the DFU yellow blink resumes. I never hit any breakpoint in my user code. If I pause in VSCode, the yellow blink stops. I can see an unknown Call Stack address in the debug window - 0x08000d64, and expanding the “Global” variables tab displays a large number of variables, but otherwise it’s unclear how to do anything.

My expectation would be that I can debug my application and/or device os code.

Any thoughts on what I might be doing wrong?

Opening DFU capable USB device...
ID 2b04:d00a
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 = 448400
Download        [=========================] 100%       448400 bytes
Download done.
File downloaded successfully
2

thanks for giving it a try :+1:

if you haven’t already, spend some time familiarizing yourself with VSCode’s basic debugging UX and options: docs

in the meantime, let’s try a few things. when you click the debugging start button (green button at the top of the debugging sidebar), we’ll automatically try to flash your device with your current firmware (using the Particle: Flash application for Debug (local) task).

so your steps should be

  1. put device into DFU mode
  2. click debugging start
  3. device will be flashed
  4. “Debug Console” panel is focused, device is paused
  5. click the continue (f5) button in the debug controls (pause, step over, in, out, etc)

you can tune this workflow via the ./.vscode/launch.json file we’ve created for you. we pull in the cortex-debug extension to facilitate debugging so atm docs are here, repo here

there are a couple of places to look for errors:

  • in the terminal panel (local compilation task output goes here - so if there was a problem compiling or flashing, it’d be here)
  • in the Debug Console’s output
  • in the Output panel (to the left of Debug Console) when you select the “Adapter Output” in the drop-down menu to the right.

i suspect there’s something a bit more interesting over in the Adapter Output log - can you share that here?

lastly, it’s helpful to provide the non-sensitive portions of the report that is generated when you run the Particle: Audit Environment command - can you share that as well?

thanks :pray:

1 Like
3

Is there a standard config for using the STLINK_v2?

Based on the existing configs in launch.json I created this

{
            "type": "cortex-debug",
            "request": "attach",
            "name": "STLINK Debugger (electron)",
            "servertype": "openocd",
            "interface": "swd",
            "device": "STM32F205RG",
            "cwd": "${workspaceRoot}",
            "executable": "${command:extension.getDebuggerExecutable}",
            "preLaunchTask": "Particle: Flash application for debug (local)",
            "armToolchainPath": "${command:extension.getDebuggerCompilerDir}",
            "svdFile": "${command:extension.getDebuggerSVDFile}",
            "searchDir": [
                "${command:extension.getDebuggerSearchDir}"
            ],
            "configFiles": [
                "interface/stlink-v2.cfg",
                "target/stm32f2x.cfg"
            ],
            "postAttachCommands": [
                "monitor reset halt"
            ],
            "windows": {
                "configFiles": [
                    "interface\\stlink_v2.cfg",
                    "target\\stm32f2x.cfg"
                ]
            }
        },

However I get the error:

Failed to lauch OpneOCD GDB Server: Timeout.

Any tips?

Thanks

4

Is there a standard config for using the STLINK_v2?

no, but what you have seems like it should work :man_shrugging:

Any tips?

not without learning more about your setup and the errors you are hitting - see here for where to look and what to share :+1:

5

Hey @m_m, really appreciate the detailed steps!

Unfortunately/Fortunately, before your reply I used my J-Link along with Segger Ozone to load the .elf file built by Workbench. That seemed to knock the device out of the weird modes it was in.

When I went back to try your steps, the issue no longer reproduced and I’m debugging successfully!

3 Likes