Debugger with Photon

Firmware
1

I just received my programmer shield and I’m trying to find instructions on connecting a debugger to the Photon.

I’m using Linux, so @AndyW if you have time to help me out I’d really appreciate it.

So far here’s what I’ve done:

  1. Download OpenOCD source code
  2. Add particle-ftdi.cfg from the programmer shield repository to the source code
  3. Compile and install OpenOCD with ./configure --enable-ftdi and make install
  4. Copy 99-openocd.rules from the OpenOCD contrib folder to /etc/udev/rules.d/ so I don’t have to do sudo openocd

I don’t know what to do next. OpenOCD needs a script to connect to the target. Is it the particle-ftdi.cfg above? When I run openocd -f particle-ftdi.cfgit complains about clock speed. If I add a clock speed line, it complains about missing transport.

This thread has a lot of discussions about OpenOCD, but a lot of steps are implied.

I’ll update the programmer shield README.md for Linux if I can figure out the steps.

2

What do lsusb and dmesg show after you plug in the shield ?

If it is configured as a standard 2 port UART, then openocd won’t see it.

I had to reprogram the PID/VID as one of the “special” devices to trigger the “skip the first port” behaviour in ftdi-sio.c

1 Like
3

Also openocd is a funny beast - about as friendly as a cornered leopard on first encounters…

It takes multiple config files, usually one for the programmer, and one for the target, then the commands are kind of bizarre (powerful, but bizarre.)

Once you get the knack of it, it’s super powerful.

1 Like
4

Lsusb shows a dual UART

Bus 001 Device 039: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC

Actually one of the missing steps is to recompile the firmware with USE_SWD_JTAG=y

make all program-dfu PARTICLE_DEVELOP=1 PLATFORM=photon USE_SWD_JTAG=y

Another step was using loading both the interface and target files in OpenOCD, and also open a port for gdb.

openocd -f interface/ftdi/particle-ftdi.cfg -f target/stm32f2x.cfg -c "gdb_port 3333"

I now see

Open On-Chip Debugger 0.9.0 (2015-08-12-12:49)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f2x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f2x.bs tap/device found: 0x06411041 (mfg: 0x020, part: 0x6411, ver: 0x0)
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints
5

yeah - hadn’t even got to the particle firmware yet - it is useful to know the DFU mode has JTAG enabled, so if you can get a photon into DFU mode, you can openocd/jtag it from there.

6

Interesting - so with the particle-ftdi.cfg from the repo, you do not need to trigger the magic ftdi-sio behaviour to skip attaching the serial driver to the first port ?

7

:laughing:

Yeah, that's the impression I got.

Alright, with the steps above and taking your tip of telnet localhost 4444 from the other thead, I was able to see that the programmer shield is connected to the Photon. Inside the telnet session I did help to see which commands were available. Typing reset did reset the Photon, so I think the next step to read up on OpenOCD, gdb, etc.

8

No. It worked fine.

One important step was copying the UDEV rules. Otherwise openocd was not able to use the device.

Here are the devices I see in /dev when plugging in the programmer shield.

crw-rw-r-- 1 root plugdev 188, 0 Aug 12 13:08 /dev/ttyUSB0
crw-rw-r-- 1 root plugdev 188, 1 Aug 12 13:08 /dev/ttyUSB1
9

Good to know - I think I was slightly ahead of that curve - so there’s at least two ways to skin this cat.

udev just fixes up permissions, I think - I had to add a rule there too for the VID/PID I hijacked.

10

I’m just mentioning it because if somebody else modifies the VID/PID, they would need to know to modify the UDEV rules, which is really not obvious…

11

One feature of openocd to exploit is the -c command line option to execute commands, that way you can have a makefile target/script to reset, program flash, etc

1 Like
12

And you will need to point gdb at port 3333 (most likely on localhost, but you never know) with the target remote command (e.g. “target remote localhost:3333”)

I usually create a gdb target that will flash the correct image(s), then leave openocd running and ready to accept gdb commands.