P&E has a new version of their GDB/Eclipse debug plugins available on their Eclipse update site, and it comes with to great features: Real Time Expressions (show variables while target is running) and FreeRTOS thread awareness 🙂
Instead creating a new project from scratch, often it is simpler to copy an existing Eclipse CDT project, then change it and go on. To copy-past the a project in Eclipse:
- Select the project in the Project Explorer View (CTRL-C on Windows)
- Then paste it in the Project Explorer View (CTRL-V on Windows), and I can specify the new name:
However, to make that process simpler, a few things have to be done right in the ‘source’ project first.
For a CubeSat project we only have a single board available. But multiple universities and developers need to have access to that board for developing and debugging the firmware. We cannot easily ship around the board: that takes a lot of time and during shipment nobody can use the board.
There is a nice feature in the Segger J-Link software which allows to share the debug connection over the network: the J-Link Remote Server. It even works nicely between different networks without complicated firewall setup:
The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
On the other side, the ‘middle and lower end’ Embedded world is fragmented and in many aspects proprietary. So it was no surprise to me when the Linux Foundation announced the ‘Zephyr’ project back in February 2016:
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
When working and debugging a bootloader, debugging can be a challenge: During debugging the bootloader, a new binary gets loaded into the microcontroller address space which is unknown to the debugger. As soon as I step into the newly loaded binary, I only see assembly code, with that ugly “No source available” in Eclipse:
But wait: GDB is able to do pretty much everything you can imagine, so here is how to debug multiple binaries with GDB and Eclipse, and to turn the above into something which is easy to debug:
To me, one of the most frustrating things working with ARM Cortex-M cores are the hard fault exceptions. I have lost several hours this week debugging and tracking an instance of a hard fault on an ARM Cortex-M0+ device.
For a university reasearch project I try to pair the Raspberry Pi 3 with a Mikroelektronika Hexiwear using BLE (Bluetooth Low Energy). Most of things worked after a lot of trial and error, but at a certain point I was stuck trying to write to send data from the Raspy to the BLE device.The Hexiwear BLE protocol description is very thin, so I ended up using a BLE sniffer to reverse engineer the protocol with Wireshark.
I’m using the NXP FRDM-K64F board in several projects: it is reasonably prices, has USB, Ethernet, micro SD card socket and connectors for Bluetooth classic and Nordic Semiconductor nRF24L01+ 2.4 GHz transceiver:
But one issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues.
The good thing with failure is: it is an opportunity to learn :-).
So here is a case: For a STEM roadshow (see “MINTomat: World’s Most Complicated Bubble Gum Automata?“), we have produced in a rush an autonomous robot with a shiny printed 3D cover:
It seems to me that not many developers use hardware trace? ARM indicates that maybe only <5% of developers are using trace. Too bad! Why are all the ARM Cortex microcontroller vendors putting a powerful hardware (and complicated!) trace engine into their devices, if only few developers are using it? Seems like a waste of silicon and an unnecessary price adder? Well, hardware trace can be a life saver: Because only with hardware trace the most complicated bugs and problems can be solved. And maybe because only the best are using it ;-).
Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
As a standard procedure, I add some console functionality to my embedded applications. That way I have a command line interface and can inspect and influence the target system. One interesting hardware feature of ARM Cortex-M is Single Wire Output (SWO): it allows to send out data (e.g. strings) over up to 32 different stimulus ports, over a single wire.
In my first post about Segger Ozone (see “First Steps with Ozone and the Segger J-Link Trace Pro“) I missed the fact that it includes support for kernels like FreeRTOS. So here is how to show the FreeRTOS (or any other RTOS) threads with Ozone:
From time to time I face some problems which are really hard to find. Mostly these kind of bugs are very timing sensitive and depend on interrupt execution order. Maybe a dangling pointer is overwriting memory, code is running wild, or some functions are not reentrant as they should be. For these kind of bugs, good tools are worth their weight in gold. The Percepio FreeRTOS+Trace and the Segger SystemView have helped me many times to narrow down such kind problems in my applications. Another ultimate tools is hardware trace: Now I have a Segger J-Trace Pro for ARM Cortex-M in my arsenal of bug extinguishing weapons on my desk:
Dear bugs, look what I have on my desk. Your hiding time is over! 🙂
In “ARM Cortex-M, Interrupts and FreeRTOS: Part 1” I started with the ARM Cortex-M interrupt system. Because the ARM implementation cann be very confusing, I confused myself and had to fix and extend the description in Part 1 :-). Thank for all the feedback and comments!
Originally I wanted to cover FreeRTOS in Part 2. Based on the questions and discussions in Part 1 I thought it might be a good idea to provide visual examples.
I kind of hoped that after “Why I don’t like printf()” and all my other articles about printf and semihosting, that topic would be 200% handled and I won’t have to deal with any more. Well, I was wrong and underestimated how the Kinetis SDK is interfering with semihosting. And I underestimated how many of my readers are still using semihosting (even as there are other and better alternatives), so I keep getting questions and requests for help. That’s ok, and I hope I can help :-).
So here is yet again another post about how to turn on semihosting with Eclipse, GNU ARM Embedded and the Kinetis SDK v2.0. This time with the FRDM-K64F board:
Getting a board from a distributor like Farnell/Element14/Mouser (add your own distributor) means that chances are high that the default firmware on it is written years from now because the inventory has not been updated, or because boards are still produced with that original firmware (because of testing?). So what happens if I use board with a firmware developed pre-Windows 8/10 area?
It might work, but chances are high that the bootloader and firmware is not ready for the ‘modern age’, and as a result the board might be bricked. If you still have a Windows 7 machine around (I do!), you are lucky. If not, then you need to read this article….