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. Particle.io 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.)
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.