We have a custom board with a P1 (SWD and serial connections only, no USB) that is giving us trouble. Before flashing it, when we first powered it up, it went into listening mode as expected (I’m assuming it came with Tinker on it.) We saw it appear in the network list on our computer, went to connect and the connection timed out. We don’t have USB, so we couldn’t get the device ID that way. A second board behaved in exactly the same manner.
Then we built an image from source based on our app (in main, % make clean all v=1 APP=ourApp PLATFORM_ID=8 USE_SWD=y MODULAR=n) and loaded that over SWD. We are using this ST-Link V2 interface + st-util. Then we get the SOS hard fault blink pattern so we try loading a another image, this time with APP=tinker, and we get the same SOS pattern.
In hindsight, flashing the FW would not have solved the original problem of getting the device ID. We were clearly flailing at this point. But this result of SOS hard fault after flashing is also unexpected. I checked the flashing logs and we never wrote anything above 0x8020000 so we did not overwrite any of the DCT/EEPROM regions so I would expect things like the server keys to be intact.
I’ve combed the forum for answers but almost everyone has USB. Any suggestions on next steps without using dfu-util?
This doesn't solve your current problem, but the second to last section of this tutorial explains how to get your device ID by SWD:
I've been meaning to figure out and write up a guide for programming firmware by SWD. I'm not sure I'll get to that soon enough for your purposes, however.
Thanks for the info @rickkas7 - we’re still having trouble getting past the SOS hard fault state.
We were able to poke at the device id in gdb with:
(gdb) target remote:4242
Remote debugging using :4242
0x08003060 in ?? ()
(gdb) set mem inaccessible-by-default off
(gdb) x/3x 0x1FFF7A10
In GDB, we found that we had to use the set inaccessible-by-default off in order to access that particular address (our dev environment is on a mac, so we’re not using ST-Link Utility App, although we do have a Windows box handy if needed).
So, we tried flashing an image with the sole purpose of setting up Wifi credentials and connects to our local AP. That also did not work - still SOS Hard Fault.
Flashing my P1 with either modules or just main does not work. I get a happy message from st-util but still SOS hard fault. I’m starting to worry maybe my ST-Link interface FW is not right… not sure.
But, my build tool-chain is good - tested that on Photon. But, after loading up a SWD enabled image on my Photon via DFU which boots fine, runs a test app fine, I cannot re-flash using SWD. I can attach via GDB, etc. but when I try to flash/load, I get verification failures in st-util. So, perhaps there’s an issue with my ST-Link/SWD setup?
There is no problem with our flashing or build environment - we have the whole thing working for Photon from zero’d out memory on v0.5.3 of the FW and Tinker app. But the same procedure using PLATFORM_ID=8 is not working for our P1, still getting SOS hard fault. Here’s a summary of all the steps we have taken to try and get our P1 board working.
Unlocked all sectors using the ST-Link Utility
Wrote zeros to sectors 0x0800000 - 0x8100000
Built bootloader from tag “v0.5.3” for P1 using:
% make clean all v=1 PLATFORM_ID=8```
- Flash bootloader.bin to 0x0800000 using ST-Link Utility
- Custom board with P1 resets into DFU mode
- Build monolithic system firmware using tinker app
```% cd ../main
% make clean all v=1 APP=tinker PLATFORM_ID=8 USE_SWD=y MODULAR=n```
- Flash tinker.bin to 0x08020000 using ST-Link Utility
- On boot, SOS Hard Fault (see [video][1])
NOTE: we don't think the problem is the board because it initially breathed blue when first applied power - although we couldn't connect to its AP. So we went directly to flashing. We are reviewing the schematic as well but we did follow the datasheet in our design.
[1]: https://drive.google.com/file/d/0B-1N2HT1giNsRjJIWHlmSFZlQjA/view?usp=sharing