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