Solid or Blinking M2 LED [Solved]

[kekeller]

When I power on the crazyflie on the M2 LED lights up. And when I enter bootloader mode by holding the power button for more than a few seconds M2 starts blinking. There is nothing else happening on the board.

For the past week everything had been working well until today. I tried using the VM to set up the debugger and it just kept not working. I was following the instructions here: https://wiki.bitcraze.io/projects:virtu ... jtag_debug

I connected the debugger and hit debug in eclipse and it opens the debug window. But I never get the chance to actually set breakpoints and step through the code as it keeps popping up with various errors (Symbol Null is not defined etc).

So I stopped eclipse and just went straight to the makefile and tried using gdb and to debug/flash it. I get an error that says "target halted due to debug-request, current mode: Thread"

1. The VCC is at 2.99V so that's not the problem.
2. I tried using the cfclient to reset the bootloader using the instructions (replug radio, etc) and nothing happens.
3. I have changed out the batteries and left the crazyflie unplugged for a few minutes.
4. I tried powering it just over USB and there is not change.
5. I have tried this in both native linux and the most recent virtual machine.
6. I tried using the cfloader flash tool but it says it can not connect to the bootloader.

It appears as if the firmware (stock, most recent pull) somehow got stuck in debug mode despite the reset and power off.

1. How can I reset the crazyflie?
2. After resetting the drone, how can I actually use the debugger to step through the code?

[tobias]

My guess is that you have erased the STM32F4 bootloader (this happens when you flash over JTAG) and didn't flash the right build. Did you build the code with DEBUG=1 and CLOAD=0.

What debugger are you using? If you setup the debugger correctly try to build and flash with

Code: Select all

make all DEBUG=1 CLOAD=0
make flash

When you do this make sure the STM32F4 is powered (blue M2 LED is on).

The debug instructions are a bit outdated and should be updated. Adding to todo list. However now it should be pretty easy to do if you are using the latest VM. Just run the "Crazyflie 2.0" debug configuration (if you are using a stlink debugger).

[kekeller]

I did not do that. I tried following the directions found here: https://wiki.bitcraze.io/projects:virtu ... jtag_debug

So I used this code and got it to flash (maybe)

Code: Select all

make all DEBUG=1 CLOAD=0
make flash

When I rebooted it the lights went back to normal blinking and I was able to enter bootloader mode using the power button.

So I tried again with the same commands after making firmware changes (turned off all but one motor in power distribution) just to check that something actually is getting flashed.

And then I get this in native linux (not virtual machine)

openocd -d2 -f interface/stlink-v2.cfg -f target/stm32f4x_stlink.cfg -c init -c targets -c "reset halt" \
-c "flash write_image erase cf2.elf" -c "verify_image cf2.elf" -c "reset run" -c shutdown
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
WARNING: target/stm32f4x_stlink.cfg is deprecated, please switch to target/stm32f4x.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.891873
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

Makefile:361: recipe for target 'flash' failed
make: *** [flash] Error 1

And so I tried again after cleaning everything and got this:

openocd -d2 -f interface/stlink-v2.cfg -f target/stm32f4x_stlink.cfg -c init -c targets -c "reset halt" \
-c "flash write_image erase cf2.elf" -c "verify_image cf2.elf" -c "reset run" -c shutdown
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
WARNING: target/stm32f4x_stlink.cfg is deprecated, please switch to target/stm32f4x.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.891873
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f4x.cpu hla_target little stm32f4x.cpu running
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080070ec msp: 0x2001fffc
auto erase enabled
Info : device id = 0x10076413
Info : flash size = 1024kbytes
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000042 msp: 0x2001fffc
wrote 262144 bytes from file cf2.elf in 9.592066s (26.689 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x2001fffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x2001fffc
verified 197024 bytes in 1.744989s (110.262 KiB/s)
shutdown command invoked

BUT it did not actually flash anything. The firmware is still the same version (all motors work).

I also tried using cload and using

Code: Select all

make clean
make PLATFORM=CF2
make cload

and I get this as the output

../crazyflie-clients-python/bin/cfloader flash cf2.bin stm32-fw
Restart the Crazyflie you want to bootload in the next
10 seconds ...
Cannot connect the bootloader!
Makefile:354: recipe for target 'cload' failed
make: *** [cload] Error 255

How can I reset everything so I can start again?

[EDIT] Using the virtual machine gets the same results as above. I am using a STM32F4 DISCOVERY Debugger.

[tobias]

The good news is that everything seems OK. Sometimes my debugger also seems to have problems during reset phase, probably some timing issue.

So when you flash a debug build you will erase the bootloader because the code will be placed first in flash. So you will have to flash the bootloader back to get that working.

Code: Select all

make all
make flash

Then preferably start in bootloader mode and flash over radio again.

So as of now using the debugger to step code can only be done by overwriting the bootloader.

[kekeller]

Thank you. Reflashing the bootloader was the correct solution. I am now able to OTA flash the firmware again.

I am still not able to use the debugger though. Using the directions linked above:

1. In Eclipse I made the project using "make DEBUG"
2. I flashed it in eclipse using "Flash using debugger"
3. In "External Tools" I selected the OpenOCD Crazyflie2.0 STM43F4 and I get the following error.

The file does not exist for the external tool named OpenOCD Crazyflie 2.0 STM32F4.

When I start poking around in the OpenOCD config settings and try to run it from the settings I get this error message.

Open On-Chip Debugger 0.7.0 (2013-10-22-17:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
debug_level: 0
WARNING: target/stm32f4x_stlink.cfg is deprecated, please switch to target/stm32f4x.cfg
Error: session's transport is not selected.
Error: unable to select a session transport. Can't continue.
shutdown command invoked
Runtime Error: /home/bitcraze/.openocd/target/stm32f4x.cfg:29: invalid command name "using_jtag"
in procedure 'script'
at file "embedded:startup.tcl", line 58
at file "/home/bitcraze/.openocd/target/stm32f4x_stlink.cfg", line 2
at file "/home/bitcraze/.openocd/target/stm32f4x.cfg", line 29

I tried looking in the cfg files but they all looked as expected.

[tobias]

Those are bit outdated instructions and now it is a bit more simple to debug with the VM by using the GNU ARM Eclipse plugin. To start debugging go into the "Run -> Debug configurations..." dialog and under "GDB OpenOCD Debugging" you should find "Crazyflie 2.0". Press the debug button and it should start the debug and hit a breakpoint at main.

[kekeller]

So I do NOT have to flash the firmware with the debugger version? Because when I try that I still get an error message.

But when I use the "run" option it opens up the debug session! BUT, it never actually runs the program.

Normally a debugger has a visible indicator when it hits the breakpoint (in this case the set one in main). And the resume button is not active. I also never get the option to actually step through the code. All those buttons are blanked out. And suspend gives an error message.

And there is the other odd issue that some normal things like uint32_t and NULL are underlined with red and the error message says "could not be resolved". There are hundreds of these errors. The build itself is fine so I am not sure why that is happening in debug mode.

Do you know are causing these issues?

[kekeller]

I got it working by deleting the virtual machine and downloading a new version. The issue with the "could not resolved" is still present but does not affect the operation.

1. Build the firmware using the debug config
2. Flash using the debugger
3. "Run -> Debug configurations..." and under "GDB OpenOCD Debugging" you should find "Crazyflie 2.0". Press the debug button and it should start the debug and hit a breakpoint at main.

From there you can set breakpoints and it functions as a normal debugger.

Don't forget to flash the bootloader back when you are done. And then flash a normal build.

[tobias]

Success, great! There are still some improvements to be done which we are discussing here.