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.
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.
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 have continued to explore my two hobbies (embedded systems, and Talking About The Weather) during these weeks of lock-down. I have finally got to the point that my Weather Station project can sit on the window shelf of my office, and show me the temperature, humidity and atmospheric pressure on the attached eInk display.
In this blog I’m going to focus on driving that display.
In an earlier tutorial I introduced using I2C with the NXP LPC55S69 on OKdo E1 board to read a Bosch BME280 environmental sensor on a Mikroe Weather Click board. The MCUXpresso Clocks, Pins and Peripheral Config tools were used to get it running. It’s all for my Weather Station project that I’ve been working on during these months of lockdown. It is starting to take shape – as you can see from the photograph:
Now I really need to start reading and writing to the BME280 sensor, and that means using the I2C driver in the lpcxpresso55s69 SDK. And so this week I’ll provide a forensic examination of the most commonly-used I2C function call.
I want to share with you a little embedded trick that I use to improve the reliability of my code. And in addition to improving reliability, the technique can be used to schedule any event to occur ‘sometime in the future’. It uses the MicroTick (UTICK) timer found on the NXP LPC55S69 microcontroller, and could be applied to any device with a simple timer.
The MicroTick timer is an elegant, thing of beauty. But there is not a driver example built into the lpcxpresso55s69 SDK, and I believe that the timer is not widely used. That means we need a tutorial!
I selected the Bosch BME280 environmental sensor as the heart of my OKdo E1-based weather station. It is convenient to use, and I can prototype with the Mikroe Weather Click board MIKROE-1978. But the sensor is accessed over I2C, and that is my least favourite of the communication interfaces. In this short tutorial, I show you how the MCUXpresso Config tools (Pins, Clocks, Peripherals) are used to set up the I2C driver from the MCUXpresso lpcxpresso55S69 SDK. And very quickly, I am able to communicate with the BME280 sensor.
I spend a lot of my time writing software to run on manufacturers’ evaluation (or development) boards. Here on Erich’s site, my blogs have been based on Cortex M33, using NXP’s LPC55S69-EVK and LPC55S16-EVK. Development boards are great – firstly you know that the suppliers’ software should run without issues, and secondly: many of the pin functions are brought out to headers, transceivers, codecs, switches and LEDs. So, whilst it is easy to get started, by definition the boards can be large physically, power hungry, and expensive.
What do you do if you need to embed a high performance microcontroller into your prototype or small production run and don’t have time (or the inclination) to spin out a PCB?
I will always take the same approach when I receive a new embedded board: firstly I want to see how quickly I can get it up-and-running, then I want to see what it does “out-of-the-box” and finally I want to find out if the board is “useful”. Does it have some features that will inspire me for new projects??
The NXP LPC55S16-EVK has some great features – CAN-FD, dual USB and a high performance Cortex M33 microcontroller, running at 150 MHz. I have an idea to use the LPC55xx series as the basis for a Weather Station. But this is only feasible if the chip has a low power consumption and can run for weeks on a small battery.
Time to run some test code and get my digital multimeter out…