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:
The ARM Cortex cores are everywhere. I like (and use) them a lot. Don’t take me wrong: maybe ARM needs some competition? It is very refreshing to see that something new is getting a lot of attention: RISC-V!
For some projects it is not possible to have the device under debug available on my desk: the board might be in another room, on another site or in a place where physical access is not possible or even dangerous. In that case an IP-based debug probe (see Debugging ARM Cores with IP based Debug Probes and Eclipse) is very useful: as long as I can access its IP address, that works fine. It is an excellent solution even if the board is moving or rotating: hook it up to a WLAN access point and I still can use it as it would be on my desk.
But what if I have a debug probe only connected to USB? This article shows how to turn a USB debug probe into a IP-based debug solution: that way I can easily debug a board from remote, connected to the network:
Sometimes I start a project with an ARM microcontroller, and in the middle of the project I find out that it was a wrong choice at the beginning and I need to switch the microcontroller derivative or even the used ARM core. With little knowledge of the project structure and the files needed, such a switch is not the easiest thing, but definitely possible.
The NXP LPC845-BRK board is a tiny an inexpensive (sub $6) breakout board. The board includes a CMSIS-DAP (LPC11U35) on-board debug probe which can be used as a debug probe to debug any NXP LPC, Kinetis or i.MX RT device 🙂
One great thing with that new NXP LPC845-BRK board is that it is possible to use it with any standard SWD/JTAG debugger, as it has the 10pin debug header present on the board. It is not populated by default, because the LPC845-BRK includes a CMSIS-DAP debug probe already. But if I want to use a SEGGER J-Link, a P&E Multilink or the NXP LPCLink2, this is certainly something to consider:
It is a common thing to boot a Linux system (see the Raspberry Pi) from a micro SD card. It is not that common for a microcontroller. The NXP i.MX RT ARM Cortex-M7 fills that gap between these two worlds. No surprise that it features a ROM bootloader which can boot from a micro SD card.
Most host or desktop systems (say Linux, Mac or Windows) have a normal use case where you start the operating system say in the morning and shut it down in the evening, and then you leave the machine. Embedded Systems are different: they are not attended, and they are supposed to run ‘forever’. Not every embedded system needs to run an OS (or in that world: Real-Time Operating System or RTOS), but the same applies here: after the RTOS is started, it is not intended that it will shutdown and restart. To the extend that you won’t they support the ‘shutdown’ and ‘restart’ functionality at all. In case of gathering coverage information this would be really useful:
coverage information from FreeRTOS application
In the case of FreeRTOS: what if I really need to shutdown the RTOS and restart it again, as by default this is not supported. This is what this article is about …