[Windows 7] Programmer shield v.1.0.0 problem

Getting Started
1

Hi,

I've just bought the Programmer Shield (v.1.0.0), because I currently have an SOS problem (the usage fault) and I have no idea what it means... so I wanted to try and debug it with the Programmer Shield... with no success.
I used this tutorial: Debugging Particle on Windows. This article is a complement to my 5… | by Julien Vanier | Medium
But when I get to the last command (arm-none-eabi-gdb -ex "target remote localhost:3333" ../build/target/user-part/platform-6-m/user-part.elf), I don't get the same results as what I should get. I assumed that the user-part.elf was the one in the firmware (firmware/build/target/user-part/platform-6-m/user-part.elf), after compiling and flashing the code with make clean all program-dfu PARTICLE_DEVELOP=1 PLATFORM=photon USE_SWD_JTAG=y.
So, once I run the command, I get:

Remote debugging using localhost:3333
0x00000000 in ?? ()
(gdb)

and if I try to run the program in gdb, I get:

The "remote" target does not support "run". Try "help target" or "continue".

Does anyone have any idea about what could be the problem?

2

Make sure you are not using pins D3 to D7 in your firmware (D7 is the blue user LED) since those pins are used by the debugger.

You are successful in running OpenOCD, right? If so, you can send commands to OpenOCD through telnet to port 4444. Try sending the reset command. Search for telnet in this article for details and screenshots.

Another thing to try is to use the debugger while the device is in DFU mode since that mode has JTAG properly enabled. You can isolate issues with the tools on the PC vs issues of turning on JTAG in your firmware.

3

I only use A5, so it doesn't come from D3 and D7. :smile:

I am successfully running OpenOCD, yes. By doing the telnet reset halt, then running gdb, I get:

Remote debugging using localhost:3333
0x08002ebc in ?? ()
(gdb)

which looks better than before, I guess. But I still get the same message if I try to run with gdb. Is it possible that something in my code makes it not possible for gdb to execute run?
Also, when I executed where in gdb, this appeared:

#0 0x08002ebc in ?? ()
#1 0xffffffff in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Is putting my device in DFU mode with the debugger the same as without? Because I didn't get a yellow light, but a "dark" blue light, and now nothing...

4

@ConfidentWreck, I had issues running OpenOCD on windows on port 3333. As with @jvanier, I had no problems when I used port 4444.

5

Thank you both for your quick replies. :smile:

It seems that I managed to make gdb work (I started the debugging steps from the beginning again, with telnet and managed to put the Photon in DFU-mode without problem this time). Although I still can’t run in gdb, I can set breakpoints and go through my code with continue, step and next.

Now it’s time for me to find where my SOS problem is!^^
Thank you again!

2 Likes
6

The most common reason for usage fault is a zero-div error.
There are other reasons but this is the easiest to produce by code :wink:

2 Likes
7

The usage fault that I used to have doesn't seem to appear again... but if it does, I'll look again for that, thanks @ScruffR!

So now, I got gdb to work and I don't have the usage fault... but I now have an SOS hard fault and I don't know if there is a problem in my circuit or in my code: I have a voltage divider with a few switches, which allow me to change the output of the voltage divider. I currently use A5 as as the output of my voltage divider, 3V3 as the VIN of my voltage divider, and GND for the ground of my circuit. That's all there is in my circuit. After switching on and off (more or less randomly) the switches for a while, my Photon crashes and send me an SOS hard fault. Would anyone have any idea about what could cause my Photon to crash?
[In case it changes anything, I wrote my code like an Arduino one, with a setup() and a loop().]

Also, I tried running gdb and I may be wrong, but it seems that at one point, it gets stuck at ../../../modules/shared/stm32f2xx/inc/user_part_export.c:78, in the module_user_loop():

(gdb) where
#0 module_user_loop()
at ../../../modules/shared/stm32f2xx/inc/user_part_export.c:78
#1 0x08060d20 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

or maybe later at src/user.cpp:

(gdb) next
serialEventRun() at src/user.cpp:91

[...] after a few next commands:

(gdb) next
0x08060d20 in ?? ()
(gdb) next
Cannot find bounds of current function
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08002ede in ?? ()

Does anyone know what might have happen?

PS: by asking for your help for an SOS fault, should I have started a new thread?

8

Debugging an SOS with the debugger is hard because there's no way to put a breakpoint just before the error occurs and get a backtrace. You can trace line by line and hope to catch the error, or you can put a breakpoint in _panic but that doesn't give you much.

If you still want to try it, try compiling the firmware in 1 ELF file instead of 3 (i.e. non-modular instead of modular). It will help get rid of the weird symbols issues you are facing since you'll have the symbols for the system and your user application in one ELF file.

See 5 steps to setup and use a debugger with the Particle Photon | by Julien Vanier | Medium

Why use MODULAR=n? With this option, only one big executable will be created instead of 2 system parts and 1 user part. It’s a lot easier to debug. Just remember to reflash your device with the modular firmware after you are done debugging.

You want to run:

cd main
make clean all program-dfu PARTICLE_DEVELOP=1 PLATFORM=photon USE_SWD_JTAG=y MODULAR=n

You can post your code here. Most often an SOS is because of a memory error (overflowing a buffer, deferencing an uninitialized pointer, using memory after delete).

2 Likes