Open Source software has been around for decades. But open source on hardware especially microcontroller is not much a reality these days. But there is something which might change this: RISC-V is a free and open RISC instruction set architecture and for me it has the potential to replace some of the proprietary architectures currently used. RISC-V is not new, but it gets more and more traction in Academia (no surprise).
I wanted to play with RISC-V for over a year, but finally a week ago I did one of these “hey, let’s buy that board” thing again. Sometimes these boards get on a pile to wait a few weeks or longer to get used, but that one I had to try out immediately :-).
The world is changing, and the say is “change is good” :-). In the software and API world, change very often means that a change results into something broken. So I had battled with semihosting working on the NXP Kinetis parts, only to find out that it does not work any more with using the latest version 2.0. The semihosting output e.g. with P&E debug connection remains empty:
Related to my earlier article about using OpenOCD, I want to share something I have learned (again) with OpenOCD v0.10.0:
I was running often into the following error:
Warn : Cannot communicate... target not halted.
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
FreeRTOS is probably the number one RTOS used, and Eclipse is likely the most popular IDE I can think of. But debugging FreeRTOS applications with Eclipse and GDB is somewhat limited? What I would like to get at the minimum is this: ability to see all the different threads in the Eclipse debug view like this:
FreeRTOS Threads in Eclipse with OpenOCD
As you might guess from that screenshot: this post is about how to make FreeRTOS tread debugging possible with Eclipse and GDB :-).
In case you face problems with launching GDB: Then I have a quick solution (well: workaround): kill the GDB server and or client process. The problem can show up in many way, but in general gdb is stuck or does not respond:
But it could be an error message like this too:
Error in services launch sequence
Starting J-Link GDB Server timed out.