While developing applications, it can happen that things go wrong. And in my case I ended up with two LPC55Sxx EVK boards on my desk, which seemed not to be usable any more. The issue: the boards were not accessible with the debug probe, because right after main they muxed the pins in a wrong way :-(.
The standard GDB debug connections (both on-board and off-board) were not able to regain access of the board, because the MCU was running into the fault condition pretty much right out of reset.
Luckily, after a lot of trial-and-error, I have found a way to recover them.
I’m not a big fan of using printf() in embedded applications, but I have to admit that in some cases it is very useful. One problem in debugging embedded systems debugging is getting values or information off the target: because of the limited resources this can be very challenging.
So why not doing this with the debugger in an automated way? And here dynamic printf breakpoints can help: it adds printf()-style output on-the-fly to your program without the need to recompile or restart your program, without the need to run printf() on the target:
The silicon shortage is still going on. While the NXP Kinetis KE devices might not be my first choice, they still seem to be available, in at least in lower quantities. This has been recognized by others, as I’m getting more and more questions and requests for the KE and KV family. This is why I un-dusted my old FRDM-KE02Z to be used with the latest MCUXpresso SDK and IDE.
And in case you want to use that board or device with semihosting, I have you covered.
I’m now in the middle of the university fall semester exam season with writing exams and grading student work, and the same time the new semester courses need to be prepared. With the global silicon and board shortage, this will be again a challenge to equip all the labs with the needed infrastructure. The good thing is that there is no shortage on software and tools side of the infrastructure: NXP released last week their new flagship Eclipse based IDE: the MCUXpresso IDE 11.5.0. Time to check it out for the upcoming lectures and classes….
Spoiler Alert: It has a new view for FreeRTOS lovers, plus new features for energy/power measurements!
Split-flap displays are electromechanical display devices, which were common in airports or railway stations a few years ago.Unfortunately, most of them are gone and replaced by LED displays. Why not create a DIY version of it?
In Spilling the Beans: C/C++ Header Files, I touched on interfaces and the difference between external and internal linkage. This article has a focus on internal linkage with using the static keyword in C.
So this might be a programming language refresher, in case you are clear about the difference between declaration and definition, or if you are wondering about internal or external linkage in C.
LoRaWAN is getting more an more popular, both for terrestrial and increasingly with low-orbit satellite systems. The ‘Long Range’ in ‘LoRa’ makes it an ideal solution for low-power and low data rate applications. For a university research project we selected the Semtech SX1261/62 transceiver together with the NXP LPC55S16 mikrocontroller. Because the board used for that project is not available for the public (yet), I share here how you can run the LoRaWAN stack with the NXP LPC55S16-EVK.
I’m pleased to announce a new release of the McuOnEclipse components, available on SourceForge. This release includes several bug fixes, support for more devices, and updated components like FreeRTOS, MinINI, Percepio Tracealyzer and SEGGER SystemView.
For more than two years I’m using the NXP LPC845 in my university courses. Beside of that it is used in many projects. First, because the LPC845-BRK board is small, breadboard friendly and inexpensive. Second, for many small projects that Cortex-M0+ provides just the right amount of processing power and memory.
If you search for ‘LPC845’ on my blog, you will find many articles about it. We are using the LPC845 in a research project, and one developer asked me why the LPC845 seems to run slower than expected. And I was sure that I wrote already an article about this, but to my disappointment: even Google did not find it? So complete this unfortunate gap, here is it: how to optimize the LPC845 and running it at full speed, with the hand-brake released.
Many embedded systems application need to store some kind of data in a persistent way: calibration values, settings or log information. For a smaller amount of data, using an external memory or file system is an overkill. In many system I’m using minINI to store key-value pars in in a ‘ini-file’ way, but it requires the use of a file system of some kind. minINI is great and efficient, and makes getting and storing data really easy. But for simple cases, a single FLASH memory page or sector is just all what I need. Instead managing that page directly, why not using minINI without a file system?