stlink v2 Debugger not working in current firmware

Firmware/software/electronics/mechanics
Post Reply
keffi
Beginner
Posts: 18
Joined: Mon Feb 25, 2019 10:35 pm

stlink v2 Debugger not working in current firmware

Post by keffi »

Hello again,

due to some suboptimal git configurations our git repository was decoupled from the bitcraze repository since last summer. This actually seemed to cause my uart-related problems discussed in another post.
Today I went for a "fresh start", so taking the current firmware and creating a new branch to integrate our developments we done so far.

However, we crucially rely on our debugging abilities with the stlink v2 debuggers to develop our algorithms. Unfortunately, debugging is not working anymore. "Flash using debugger" seems to work, but I can not start the firmware in debug mode.
To clarify, debugging does also not work for the unmodified master being the current bitcraze firmware - so I do not expect issues referring to our modifications.

On the other hand, compile works out, I just had to comment some lines in pulse_processor_v2 since they seemed to be unused and I got compile errors. Commenting these lines there is just one warning concerning cygwin, but it works out anyway.

I am working on a Ubuntu 18.04 machine with Eclipse, my Debug Configuration seems to be correct, my openocd path is pointing to the openocd file and the remaining settings are:
Gdb Port is 3333
Telnet Port is 4444
Config Options are -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c targets

The gdb client setting is currently arm-none-eadi-gdb, which is also within the gdb_path (In fact I tried different settings but none worked so far).

The error I get is "Error while launching command: usr/bin/arm-none-eabi --version"

In the make-file you provided you are using

CROSS_COMPILE ?= arm-none-eabi-

although on your git page (https://github.com/bitcraze/crazyflie-firmware) you wrote "Note: Do not use the gcc-arm-none-eabi package that is part of the Ubuntu repository as this is outdated". Maybe this is related to my issue (Although, compile/Cload seems to work)? At least it leads to some confusion on my side. I followed your advice in the lines above

sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt install gcc-arm-embedded

but what would be the correct choice now arm-none-gcc/arm-none-gcc-7.xx ? I have a couple of files in my directory but no one reads "gcc-arm-none-eabi"

Remark: You are also using OPENOCD_TARGET ?= target/stm32f4x_stlink.cfg within your makefile. I tried stm32f4x.cfg but this seems not to have any effect.

So finally, I have no clue what to try now. Any advice is highly appreciated and please take into account that I am not a very experienced in those toolchain issues yet (hopefully it will become better at some point).


Thank you in advance

Klaus
keffi
Beginner
Posts: 18
Joined: Mon Feb 25, 2019 10:35 pm

Re: stlink v2 Debugger not working in current firmware

Post by keffi »

Hello again,

I could not leave this problem aside. For some reason, after lunch the debugger could be launched again (Maybe, I just should have tried a reboot although I thought that I did this....puh ) and stops in main as desired.

However, any Crazyflie (2.0 and 2.1) which is equipped with a Flow Deck v2 and a LPS Deck runs into a Firmware Crash when I starting the scheduler which seems to be quite odd. At least for the CF 2.0 this is also the case when flashing with cload - I haven't tried the 2.1 yet. Dettaching the LPS Deck the firmware runs in the usual manner.
I anticipate this problem to be on my side, but I have done no modifications to the bitcraze firmware version for these principal debugging checks. So even without my code, I get this problem. Maybe I have some compiler issue so this part of my previous post still remains open. I will try to reinstall my toolchain this week.

Somehow off-topic: I also tried my branch of some sort of path planning algorithm and got a compile error since .bss does not fit into the RAM: I had to decrease my planning roadmap which I did not have to do for the early 2019 firmware. So RAM usage of the firmware seems to be increased.
For our future developments: What would be an efficient way to decrease RAM usage (i.e. we do not use a lighthouse deck, and for the LPS we are going for TdoA3 preferable - in fact we are using LPS, Flow Deck v2 and plan to use the MR Deck soon) wihtout losing track with your updates and bugfixes? Using compile flags maybe?

As you see, these things bother me and it's difficult to leave them aside. So any advice would help.
keffi
Beginner
Posts: 18
Joined: Mon Feb 25, 2019 10:35 pm

Re: stlink v2 Debugger not working in current firmware

Post by keffi »

Hello,

a short update: I just received a message of my students: He experienced the same behavior: the unmodified bitcraze-firmware crashes when debugging with Flow Deck v2 and LPS Deck attached to the Crazyflie 2.0.
I have to stress: He is set up his toolchain under windows (cygwin) completely independent from my Ubuntu 18.04 toolchain setup. So maybe we an issue on the bitcraze side.....
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: stlink v2 Debugger not working in current firmware

Post by kimberly »

Hi!

Sorry, just trying to get the picture of what you are asking for in this thread. So you are trying to get debugging of the crazyflie-firmware to work on both Windows and Ubuntu 18.04? On windows I haven't managed myself yet, but for ubuntu I was able to debug with a pretty recent version of the firmware.

So in general for debugging, we advice to use GDB through and openocd port. That is the most stable way. Eclipse has an seperate debug tab for that, and that has been documented here:https://www.bitcraze.io/documentation/r ... debugging/.

I use Visual Code myself now these days. Let me show my settings for those.

Ubuntu 18.04
VScode

In one terminal:

Code: Select all

make openocd
or

Code: Select all

openocd -d2 -f interface/stlink-v2.cfg  -f target/stm32f4x_stlink.cfg -c init -c targets -c "reset halt" 
And then you start a debugging environment in VScode with this in the launch.json

Code: Select all

"name": "GDB",
"type": "gdb",
"request": "launch",
"cwd": "${workspaceRoot}",
 "target": "${workspaceRoot}/cf2.elf",
"gdbpath" : "/usr/bin/arm-none-eabi-gdb",
"autorun": 
"target remote localhost:3333",
 "symbol-file ./cf2.elf"
]
 
kimberly
Bitcraze
Posts: 1050
Joined: Fri Jul 06, 2018 11:13 am

Re: stlink v2 Debugger not working in current firmware

Post by kimberly »

For the other issues you are experiencing, like the RAM issue, could you please start a new forum thread? Than it will be possible for us to answer them in order and it is also better searchable for the rest of the users.
keffi
Beginner
Posts: 18
Joined: Mon Feb 25, 2019 10:35 pm

Re: stlink v2 Debugger not working in current firmware

Post by keffi »

Hello Kimberly,

yeah sorry, in fact it was a tough fight on my side with some up and downs concerning the debugger and some stuff has become mixed up:

In fact we are working as a group and all members using stlink-v2 debuggers and had no trouble working with the firmware from early 2019 as basis. However, due to the progress from bitcraze and some desirable functionality, we decided to catch up with the current firmware last weekend. This has caused some trouble, causing some chaotic forum messages, there was something interfering concerning general debug settings on my side, but I solved this.

Current situation:
We have two Notebooks, one Windows with Eclipse (using cygwin) and one Ubuntu 18.04 with Eclipse and a separate toolchain we setup completely independent from each other. Since we have two different, decoupled systems which worked out with previous firmware versions it seems to be unlikely that our problem is related to the general debug settings. I think, our setup is ok.

Our Problem is:
On Both systems, we can take your current firmware and use our stlink v2 debuggers as long as we do not connect any decks. In this configuration everything seems to work smoothly.
But: Attaching the flow deck v2 and the LPS deck simultaneously (but we definitely need them simultaneously in the foreseeable future), the debugger starts, then stops at main as desired but proceeding to the Scheduler the firmware crashes with this uart_syslink-assert message.
So to recover our problem at your side, you would have to attach those decks. For me, I experienced this issue with the Crazyflie 2.0 and 2.1, the student (windows system) only has a 2.0 currently. It would be very interesting to check, whether you could reproduce this problem. Otherwise we would be somehow lost.....
This is kind of disappointing, since we hoped to solve the flow deck v2/LPS deck instability we encountered in the past when modifying the firmware.

Again, sorry for the mixed up problems, I hope it becomes obvious now what the problem is. Concerning RAM, I will open a separate thread.
Thank you in advance for any help
tobias
Bitcraze
Posts: 2339
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: stlink v2 Debugger not working in current firmware

Post by tobias »

I think I know what it is. The problem is that when the STM32 is halted, the nRF51 isn't, which continue sending messeges. If it is halted in the middle of a message this will become corrupted. This happes during the break at main and afterwards an ASSERT is hit. There is actually an issue about this but no implemented solution yet.

The quick way to fix this is to comment out all the IF_DEBUG_ASSERT in uart_syslink.c
keffi
Beginner
Posts: 18
Joined: Mon Feb 25, 2019 10:35 pm

Re: stlink v2 Debugger not working in current firmware

Post by keffi »

Hello Tobias,

this definitely solved my problem, it even works out for my branch containing my modifications so I can proceed working on my algorithm

Thank you very much

Klaus
Post Reply