Programmer Shield + SWD

I am trying to use the new Programmer shield with OpenOCD and SWD via the 20-Pin JTAG header on the board. I have confirmed that OpenOCD works with my Photon but I am struggling with the SWD connection from the JTAG pins. This is my cfg file that I have tried which is an edit of the Particle-ftdi.cfg but trying to add the bits for SWD. Do any of the smart guys out there no where I can find the proper values for this cfg file?
@mohit I think you built the shield so tagging you in hopes you might know already.

The goal is to be able to support Particle and Bluz debugging/flashing from the Particle Programmer…

interface ftdi
ftdi_vid_pid 0x0403 0x6010
#ftdi_device_desc "Particle FT2232"

ftdi_channel 0
ftdi_layout_init 0x0008 0x180b
ftdi_layout_signal SWD_EN -data 0x2000
ftdi_layout_signal nTRST -data 0x0200 -oe 0x0010
ftdi_layout_signal nSRST -data 0x0090 -oe 0x0040
ftdi_layout_signal SWDIO_OE -ndata 0x1000
1 Like

@BDub Any input on this one?

This is doable. Let me take a look at this today!

Awesome. I can test late afternoon if you get something pulled together.

I am struggling with the programmer as well. I am using the WICED tools to develop my solution with the intent of starting production with a Photon module and eventually switching to a P0/USI module after the software is stable and the product proves successful. I am specifically using the BCM943362WCD4_EVB for development. I am using OS X for development. I have had no issues with the Broadcom tools or EVB, but my initial experience programming the Photon has not been what I expected. I expected that I could talk to and program the Photon with the "Programmer Shield". After a few hours, I'm still struggling. Initially I tried the methods described in several sites.

After having no success, I followed this process:

It at least set up the FT2232H exactly the same way as the EVB. I've studied all the schematics and pin outs and I'm still coming up empty. I've tried about every configuration of the .CFG files recommended.

I get:
**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****

I have looked at about everything I can think of and was wondering if anyone can share the secret to using the "Programmer Shield".

I can work with my Photon with no problems. What is the OpenOCD command you are using?

Before I answer the question, let me say exactly how and why I got myself here. I am developing a product on the WICED tools set. This is a much more complicated development environment than the Particle environment. I have developed my solution using the Broadcom WICED Eclipse environment. I want to plug my Photon programmer into my OS X development system and not have to do the rumored loading and unloading of drivers as described on various other threads. Therefore, I figured the WICED tools worked well enough that I could morph my Photon programmer and Photon to look like the WICED Evaluation board. I followed a process described on Broadcom's community board that allowed me to copy an image to the 93C46 on the programmer to make the programmer appear like the WICED EVB. That was easy. At the moment of truth, it failed. After looking at the debug messages from OpenOCD and digging a little, I finally found the key. protects memory so that the device is recoverable.

To answer the question:

./openocd-all-brcm-libftdi -f Photon-wiced.cfg -f stm32f2x.cfg -c "gdb_port 4444"

(note that I've shortened/deleted directory paths.)

"Photo-wiced.cfg" is:
telnet_port 4444
gdb_port 3333

interface ft2232
ft2232_layout BCM9WCD1EVAL1
ft2232_vid_pid 0x0a5c 0x43fa

reset_config trst_and_srst srst_push_pull srst_nogate connect_assert_srst

Now, for the problem. I have code running over there, just not the wifi part. I am still looking at that to see why. However I discovered that Particle attempted to protect us against ourselves by protecting various blocks of code.

telnet: connect to address ::1: Connection refused
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger

flash info 0
device id = 0x20036411
flash size = 1024kbytes
#0 : stm32f2x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
# 0: 0x00000000 (0x4000 16kB) protected
# 1: 0x00004000 (0x4000 16kB) not protected
# 2: 0x00008000 (0x4000 16kB) not protected
# 3: 0x0000c000 (0x4000 16kB) not protected
# 4: 0x00010000 (0x10000 64kB) not protected
# 5: 0x00020000 (0x20000 128kB) protected
# 6: 0x00040000 (0x20000 128kB) protected
# 7: 0x00060000 (0x20000 128kB) protected
# 8: 0x00080000 (0x20000 128kB) protected
# 9: 0x000a0000 (0x20000 128kB) not protected
# 10: 0x000c0000 (0x20000 128kB) not protected
# 11: 0x000e0000 (0x20000 128kB) not protected
STM32F2xx - Rev: X

Once I saw this, I knew the problem and the solution. For those who are faint-of-heart. Don't do this:

flash protect 0 0 11 off
cleared protection for sectors 0 through 11 on flash bank 0

Hope this helps somebody else save a bunch of time if they are doing the same thing.

@mohit Any progress? I broke down and bought a ST-Link v2 so I could move forward on my project but I still think this would be a great thing to get done.

I don’t think that the Programmer Shield supports SWD without modification. The SWDIO is bidirectional, but the FT2232H. Other JTAG devices using the FT2232H implement the bidirectional pin with external logic

I am also trying this, but no luck so far.
I am using all pins, except the 2 SWD pins, so JTAG is not an option.

I used an ST-link with SWD before, so I am sure the hardware is fine.

The SWD IO pin is shared with TMS, so I would guess something like this:

# Particle Industries, Inc.
# Configuration file for the Particle Programmer Shield
# Author: Mohit Bhoite
# v0.0.1

interface ftdi
ftdi_vid_pid 0x0403 0x6010
#ftdi_device_desc "Particle-Programmer-Shield"

ftdi_layout_init 0x0008 0x180b
ftdi_layout_signal nTRST -data 0x0200 -oe 0x0010
ftdi_layout_signal nSRST -data 0x0090 -oe 0x0040

ftdi_layout_signal SWD_EN -nalias nTRST
ftdi_layout_signal SWDIO_OE -alias TMS

transport select swd

Based on:

But above fails of course because TMS is undefined. What would be the right definition?
And is it really possible?
I am going back to ST-LINK for now.

This is an old thread now, but it seems to be the most on-point to answer the question “can I use the Particle Programmer Shield to program/debug my SWD-only device?” The answer seems to be no, but I was hoping to see a staffer reply definitively. Any news?

After googling around to get the particle programmer SWD capable I found this hack on

I did not test this yet but it should work without cutting traces by using jumper wires and the JTAG header to connect the resistor and the particle photon to the programmer…

“There is a configuration file called “swd-resistor-hack.cfg” that includes a wiring diagram.”