I really love clocks. I think this is I am living here in Switzerland. Beside of that: clock projects are just fun :-). After I have completed a single clock using stepper motors (see “DIY Stepper Motor Clock with NXP LPC845-BRK“), I wanted to build a special one which is able to show up to four different time zones: Below an example with London (UK), New York (USA), Beijing (China) and Lucerne (Switzerland):
In “Eclipse JTAG Debugging the ESP32 with a SEGGER J-Link” I used a SEGGER J-Link to debug an ESP32 device with JTAG. I looked at using one of the FTDI FT2232HL development boards which are supported by OpenOCD. The FT2232HL is dual high-speed USB to UART/FIFO device, and similar FTDI devices are used on many boards as UART to USB converters. With OpenOCD these devices can be turned into inexpensive JTAG debug probes. This article shows how to use a $10 FTDI board as JTAG interface to program and debug the Espressif ESP32.
Stack overflows are probably the number 1 enemy of embedded applications: a call to a a printf() monster likely will use too much stack space, resulting in overwritten memory and crashing applications. But stack memory is limited and expensive on these devices, so you don’t want to spend too much space for it. But for sure not to little too. Or bad things will happen.
The Eclipse based MCUXpresso IDE has a ‘Heap and Stack Usage’ view which can be used to monitor the stack usage and shows that a stack overflow happened:
Heap and Stack Usage
But this is using the help of the debugger: how to catch stack overflows at runtime without the need of a debugger? There is an option in the GNU gcc compiler to help with this kind of situation, even if it was not originally intended for something different. Continue reading →
When Espressif released in 2014 their first WiFi ESP8266 transceiver, they took over at least the hobby market with their inexpensive wireless devices. Yet again, the successor ESP32 device is used in many projects. Rightfully there are many other industrial Wi-Fi solutions, but Espressif opened up the door for Wi-Fi in many low cost projects. Many projects use the ESP devices in an Arduino environment which basically means decent debugging except using printf() style which is … hmmm … better than nothing.
What is maybe not known to many ESP32 users: there *is* actually a way to use JTAG with the ESP32 devices :-). It requires some extra tools and setup, but with I have a decent Eclipse based way to debug the code. And this is what this article is about: how to use a SEGGER J-Link with Eclipse and OpenOCD for JTAG debugging the ESP32.
In my previous article “Seeed Studio Arch Mix NXP i.MX RT1052 Board” I described how I can use and debug the Seeed Arch Mix Board. But so far I only had things running in RAM. Ultimately I want to use the QSPI FLASH memory on the device with my firmware and running code on it. This article shows how to get from RAM execution to SPI FLASH in-place execution (XiP).
The Seeed Studio ‘Arch Mix’ board is a small and versatile development board with an NXP i.MX RT1052 on it, and it costs only $29.90. So I was not able to resist and just have ordered one so I can explore it.
By default, Eclipse provides ‘stop-mode-debugging’: in order to inspect the target code and data, I have to stop the target. But with the right extensions as present in the Eclipse based MCUXpresso IDE, it is possible to inspect the target even while it is running.
The ‘Black Magic Probe’ (or in short: BMP) is a very small and open source JTAG/SWD debug probe with a build-in GDB Server. I saw that probe referenced in different places, so I thought I try it out with a few of my NXP LPC and Kinetis boards:
A few days ago NXP has released a new version of their Eclipse IDE flagship: the MCUXpresso IDE v11.0.
NXP MCUXpresso IDE V11.0.0
The previous v10.3.1 was released back in Feb 2019, and the 11.0 now in June this year matches up with the Fall university semester. I appreciate that the releases are about every 6 months, so this gives me time to use it in my university lecture material and lab work. I had the weekend for trying it out, and I’m very pleased.
With the cost of an single pin, many ARM Cortex-M boards including the NXP i.MX RT1064 can produde SWO data: think about a pin able to stream data out of the chip in realtime. For example interrupt activity which otherwise might be hard to capture:
New ‘things’ start to pop up, useful or not: From smart bulbs (Philips Hue), thermostats (Nest), smart TV (Samsung and others) up to voice assistants (Alexa, Cortana, Google). You might even have installed one of these, right? What about temperature and humidity sensors? Probably there is nothing wrong with that?
But what would you think if one morning you find a strange unknown device installed under your working desk, connected to the cloud and internet?
The ARM TrustZone is an optional secu=rity feature for Cortex-M33 which shall improve the security for embedded applications running on microcontroller as the NXP LPC55S69 (dual-core M33) on the LPC55S69-EVK.
My mantra is *not* to use any floating point data types in embedded applications, or at least to avoid them whenever possible: for most applications they are not necessary and can be replaced by fixed point operations. Not only floating point operations have numerical problems, they can lead to performance problems as in the following (simplified) example: