P2: program without USB

So, we just decided to move our project based on Argon to the P2, since the Argon is being phased out, but we may have mistakenly decided to just keep a programming connector (SWDIO/SWCLK) and get rid of the USB.

Unfortunately, when trying to program our board today (DeviceOS 5.3.0), I was not able to do it. Device keeps blinking dark blue right after a short burst of white at boot. I’m using the Particle Debugger. I tried to drop the hex file in the DAPLINK folder, but that didn’t work. The only thing I could do was to reflash the system, following the specific instructions using openOCD, but then it mentions flashing the app using USB in DFU mode, which obviously I can’t do.

Is there a way to figure the address to flash the app at using the openOCD method? Or any other valid method using RX/TX, or other signals?

Update: I forgot, the board has an Ethernet module on it (W5500, similar pins use as the Ethernet featherwing, SPI + RST/INT/CS on D3,D4,D5). Can’t connect to Ethernet or Wifi, not sure how to do the initial config either.

You can program the P2 using SWD/JTAG, with some caveats:

  • I never got dragging .hex files onto the DAPLINK volume to work. You can’t drop .bin files on the volume for any device, since the .bin files don’t indicate the address to flash to, unlike the .hex files.
  • OpenOCD does work, however. See the instructions here
  • Makes sure you never chip erase a P2! You will never be able to use it again.
  • Never flash the p2-prebootloader-mbr binary and do not flash anything to address 0. The reason is that each device has a unique prebootloader-mbr that is flashed at the factory with its own secure boot encryption key. If you overwrite this, the device cannot be booted because the encryption key no longer matches.
  • I never got the Segger J/LINK to work because it does not have the right MCU configuration file for the RTL8721D. CMSIS/DAP debuggers including both the Particle debugger and generic CMSIS/DAP debuggers generally work.
  • Beware of flashing user firmware binaries by direct SWD. The start address varies depending on the size of the user firmware binary.
  • The hex file generator makes a hex file with the correct data, but you need to flash it using openocd instead of drag-and-drop.
1 Like

Any command I can use specifically with openocd to flash the hex file on the Realtek? The command I saw in your doc are either for the NRF or for the STM32… The flash script (and the Tcl extension) seem to only handle .bin, but as you mention, there’s no obvious address to use for the app in .bin format.

So, with the hex generator preparing the proper hex file, how can I flash it to the P2 with OpenOCD?

The flashing script here is the best way to call OpenOCD with the right options, but if you have your own custom solution you can just look at the options it passes and do the same thing.

Yes, I used it for the first steps (flashing the system), but I still have no clue what address to pass if I use my own .bin for the app (or even tinker). The last step is “use usb + dfu mode” to flash the app, but there I’m stuck since USB is not available (and won’t be for factory flashing)

I looked into the Tcl script, and it requires the address to be passed. There’s no handling of hex files specifically (or I missed it). So, no “-c program xxxx.hex” option, unfortunately.

I’m waiting for some connector from Amazon to try to wire it to the D+/D- pin, but that’s a big bummer if we have to update our PCBs and add a USB connector eventually. We thought the whole flashing process on the P2 could be handled fully through the SWD interface…

Oh, right. Sorry about that. I also ran into a problem using the .hex with OpenOCD on the RTL872x. I think that’s fixable, but I couldn’t get the right options to make it work.

The next best solution is to determine the correct starting address for the user firmware binary. Fortunately the address is the first 4 bytes of the .bin file in little-endian byte order, so 0x085f7000 in the example below.

The address is always aligned on a 4096 byte boundary (size of the flash sector).

% od -t x1 p2-tinker@3.2.1-p2.2.bin| more
0000000    00  70  5f  08  fc  ff  5f  08  00  00  06  00  20  00  05  01
0000020    04  01  8b  0c  00  00  00  00  0e  48  0f  49  08  b5  88  42
1 Like

Ahhhh. Much better, thanks!!! :smiley:

I think I’ll do a quick script to capture and automate that. Should be fairly simple.

But first, I’ll test flashing my app.

Also, do I need the wifi to be setup? Since I have no USB, I assume I can’t go through the setup process, which also may explain the fact the device keeps blinking blue… Is the setup done flag still relevant on the P2? Since I won’t be using the wifi (due to having Ethernet on board), and assuming the Ethernet module will work fine, I think the only issue could be the setup done flag that may need to be set manually.

There is no setup bit on the P2/Photon 2. However, if the device does not have Wi-Fi credentials then it will go into blinking blue in either of these cases:

  • The application uses AUTOMATIC or SEMI_AUTOMATIC and connects to the cloud. The default Tinker app will cause this.
  • The device has missing module dependencies and needs to get online to resolve those OTA.

Got it. Thanks. I’ll test that and will let you know if problem disappeared.

In the meantime, a little script to grab the address and flash the bin:


if [ -z "$1" ]; then
	echo "usage: $(basename $0) <app>.bin"
addr=$(xxd -d "$1"|awk '/^00000000:/ { printf("%s", substr($3,3,4) substr($3,1,2) substr($2,3,4) substr($2,1,2))}')
sh flash.sh rtl872x.tcl $1 $addr

This script should be in the same folder as the flash.sh script

Update: fixed missing Tcl script in flash.sh call
Update 2: a version you can run where the bin is (your working directory):


path=$(dirname $0)

if [ -z "$1" ]; then
	echo "usage: $(basename $0) <app>.bin"

cp $1 $path/

cd $path
bin=$(basename $1)
addr=$(xxd -d $1|awk '/^00000000:/ { printf("0x%s", substr($3,3,4) substr($3,1,2) substr($2,3,4) substr($2,1,2))}')
sh flash.sh rtl872x.tcl $bin $addr
rm $bin

FYI, using xxd on the mac, not od. output of xxd looks slightly different, like this:

00000000: 0050 5f08 fcff 5f08 0000 0600 2000 0501  .P_..._..... ...

OK, so good news, app was not connecting fine on 5.3.0 but I just tested on 5.3.1 and it seems to connect now.

Thanks, @rickkas7 for the help :slight_smile:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.