Debugging with STlink-V2 -- target voltage too low

[clclmama]

Hi!

I am working with the crazyflie using the St-Link V2 and the debug adapter.
In the beginning everything was working fine, I could run "make openocd" and debug from another terminal window using "make gdb", I also run some python scripts that connected to openocd using telnet.

Suddenly and quickly things degraded and openocd started having problems connecting to the cf platform.
According to the openocd printouts it seems that the problem is the target voltage is too low: at most I get 1.54V (just enough to get it to start but then it fails soon after) but it is usually below 1V and close to 0V. I am not sure what it was before since I didn't pay attention to it but it looks like it should be above 3V. I am not sure this is useful but the value 1.54V is the same that I get if I run "make openocd" and the crazyflie is unplugged. Otherwise with the crazyflie connected the terminal printouts looks something like this:

Code: Select all

openocd -d2 -f interface/stlink-v2.cfg  -f target/stm32f4x_stlink.cfg -c init -c targets -c "\$_TARGETNAME configure -rtos auto"
Open On-Chip Debugger 0.10.0
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 v37 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 0.001567
Error: target voltage may be too low for reliable debugging
Error: init mode failed (unable to connect to the target)
in procedure 'init' 
in procedure 'ocd_bouncer'

make: *** [openocd] Error 1

or like this (when it manages to connect for short):

Code: Select all

openocd -d2 -f interface/stlink-v2.cfg  -f target/stm32f4x_stlink.cfg -c init -c targets -c "\$_TARGETNAME configure -rtos auto"
Open On-Chip Debugger 0.10.0
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 v37 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 1.455353
Error: target voltage may be too low for reliable debugging
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 300ms
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32f4x.cpu       hla_target little stm32f4x.cpu       unknown
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 700ms

Following recommendations from several google searches I tried the following:
- I updated the stlink firmware
- I tried different firmware versions (it could have been some recent low power setting of the MCU, at the beginning I was using an older version of the firmware)
but the problem persists.
I thought it could be some contact in the cables that are wearing out, but everything is very new and seems in good condition.

I am using mac and tried also with your virtual machine but I get the same errors.

One thing that could have cause the problem is that I did try some "wild" and low-level memory writings through openocd, like for example:

Code: Select all

mww 0x2000c810 0

but I guess it should be nothing that cannot be fixed by re-flashing the firmware, or am I wrong?
Do you have any guess on what I might have broken and how to fix it?
Any reset more radical than re-flashing the firmware that I could try?

Thanks a lot in advance for any help
Claudio

[kimberly]

Hi!

Thank you for your elaborate problem definition! Makes it very clear of what you are working on.

I'm not super knowledgeable with troubleshooting the debugger but I have worked with it before (not on a mac though but an ubuntu). So I will try to help while the rest is still on their holiday

So you are trying to debug the STM chip right? Random memory writes I can imagine to be a bit tricky with what results out of this. As long as the bootloader is not written on, which is on address 0x08000000 - 0x08004000. This will break the ability to do over air update and I don't know how many other things it might break as well. Do you remember which addresses you wrote something on or was this random?

You mentioned re-flashing the firmware, so is this already something that you have tried? Over air with make cload or through the ST link with make flash.

[clclmama]

Hi Kimberly,

thanks a lot for the quick reply!

The crazyflie itself seems healthy, I manage to connect to it both with the radio and the usb cable and it flies. I reflashed the firmware several times with different versions. What I cannot do it flashing through the stlink with "make flash", I get the same errors as with "make openocd". Also, I reflashed the eeprom using the provided python script.

I was using openocd to write to addresses that I got through gdb, addresses that should contain variables with the sensors data (what I want to do is to feed the firmware with artificial sensor data so I can execute flight time without actually flying the drone). So, I query gdb with something like

Code: Select all

p &sensordata.acc.x

and then use the retrieved address. This shouldn't have accessed other random parts of the memory (and in fact in the beginning it didn't give problems).

I tried now with another laptop (windows machine with the bitcraze vm) and got the same behaviour. This makes me exclude that the problem was my usb port (it gave me problems in the past and it could have been that according to some google search).

I find it weird that if I run "make openocd" when the crazyflie is turned off or even unplugged (but the stlink is plugged) I get in the printout "Info : Target voltage: 1.543081". But that voltage should be set by the target (hence the crazyflie) according to my (very limited) understanding. Perhaps I the stlink is damaged?

I should be able, in about one week, to test it with another crazyflie and therefore rule out if it is a problem with the stlink+debugger adapter or the crazyflie itself.. but not sure it will actually help and was hoping not to be stuck for so long..

[kimberly]

Ah oke if you are able to flash it over air then there is probably nothing wrong with the crazyflie or its bootloader. Also it seems that you have done what I would have done as well to troubleshoot the debugger...

Since it was working fine before, it might be that there is a cable breakage somewhere.... I would guess that the black and white wire from the debug adapter to the crazyflie stm, so maybe if you have a multimeter somewhere where you can test the ends of the cable? Other than that the gray lint cable might be to blame, although I haven't really managed to break one of those in my lifetime.

[clclmama]

Alright, so at least we have reached the same conclusion...
I am not able to test the cable now but will do that as soon as I can access the tools.

I did some more googling and bumped into this:
https://www.openstm32.org/tiki-view_for ... %20voltage
it is a different board but same debugger link and same symptoms (target voltage too low).
The solution proposed is to connect pin1 and pin19 of the 20 pin JTAG wire (the grey one). I did it and it works!!

I am not sure that this is a "clean" solution though, according to the stlink manual (https://www.st.com/resource/en/user_man ... ronics.pdf) it seems that in this way instead of getting the voltage from the crazyflie board we "cheat" and get it from the stlink itself. I am not sure what are the potential consequences of this?
Also, it still remains the question of why it stopped working in the first place..

I will work with this for now, when possible I will investigate it further and eventually post any findings here for the future users.
Thanks for the support!

[arnaud]

It does seems to me that there is somehow a connection problem with the target VCC pin.

One consequence of not using the target-vcc voltage but forcing the ST-link to 3.3V is that the voltage of the debug signal (3.3V) does not match the voltage of the Crazyflie's STM32 (3.0V) anymore. Though, I think this is still within acceptable range for the pins so it should not cause any practical problem.

[clclmama]

I got to test the cable and test the st-link against another crazyflie.
It turned out it was actually the pin on the port on the crazyflie that was damaged... apparently I was sloppy when I checked it.

Thanks a lot for the help!
Claudio

[kimberly]

Ah good to know! thanks for the update.