The MCU-Link is an inexpensive CMSIS-DAP debug probe from NXP. It can be used as a GDB server debug probe, and as such it includes scripting support. This scripting can be very useful in some cases where the MCU cannot be accessed by a normal debug session. This happens for example if students are not pay attention what binary they flash to which device, causing an MCU to potentially get ‘bricked’.
Sometimes it makes sense to write everything in assembly, even these days. For example if using a tiny microcontroller. Or just if one just don’t need all the productivity of the C/C++ tools. And it is a good educational experience: getting hands-on on the lower levels.
GDB is the de-facto debugging engine and debug connection for micro-controllers these days: it is versatile and with its client-server architecture very flexible and powerful, and pretty much every debug probe and vendor (PEMICRO, SEGGER, OpenOCD, pyOCD, …) offers it. But a GDB server or command line implementation was not available for the NXP LinkServer family of debug probes (LPC-Link, MCU-Link, MCU-Link Pro). This has changed now: LinkServer is available as command line tool and can be used as GDB Server:
LinkServer as GDB Server with Eclipse
With the new LinkServer package I do not only get a gdb server implementation: I have now a command line tool I can use for automation and all kind of different things: programming boards, erasing flash, and so on.
The ARM Cortex M architecture has many features which are underused, probably simply because engineers are not aware of it. SWO (Single Wire Output) is a single trace pin of the ARM Cortex-M CoreSight debug block. trace pin uses the ITM (Instruction Trace Macrocell) on ARM Cortex. It provides a serial output channel, at a high speed higher than the usual UART, because it is clocked at half or a quarter of the core clock frequency, depending on the core and implementation.
As such, it is an ideal high speed output channel to send text or data to the host. This is how it is usually used, but what is unknown to many: it can be used in a bidirectional way with the help of the debugger.
The topic of this article: how to redirect standard I/O like printf() or scanf() using the SWO ITM console: means both sending *and* receiving data over the SWO debug channel: that way I can use it as a kind of UART with a single pin only.
It is the exam and grading time at the university, and the same time I’m preparing the lectures and labs for the new semester starting mid of February. I’m always heading for using the latest and greatest tools in my labs. A few days ago, NXP released the new version of the MCUXpresso IDE, version 11.7.0. Time to check it out…
MCU vendors offer SDKs and configuration tools: that’s a good thing, because that way I can get started quickly and get something up and running ideally in a few minutes. But this gets you into a dependency on tools, SDK and configuration tools too: changing later from one MCU to another can be difficult and time consuming. So why not get started with a ‘bare’ project, using general available tools, just with a basic initialization (clocking, startup code, CMSIS), even with the silicon vendor provided IDE and basic support files?
In this case, I show how you easily can do this with CMake, make and Eclipse, without the (direct) need of an SDK.
If you are in the electronics or microcontroller business: you very well know the problems with chip and silicon availability. What was supposed to last maybe for a few months starting with COVID-19 is still a problem in 2022: chips are not available or the price has skyrocket.
Cost-effective usage of NXP LPC804 with WLCSP20 Package
We at the Lucerne University are using NXP Kinetis micro controllers which seem to be affected by the silicon shortage somewhat more than any other devices? When looking that the usual sources, it was clear some are still available, but in a rather exotic WLCSP package. So the question is: can it be useful?