Following up on the last piece about the NXP i.MX 7, this article looks at the Cortex-M4 companion of the A7 present in the i.MX 7. Or to put it another way, a Kinetis-on-chip since it’s very similar to a high-end Cortex-M4 based Kinetis. This article summarizes my experience writing a brand new bare metal bring up for the i.MX 7. I’ll conclude with some benchmarks.
One of our specialities at JBLopen is board bring-up, either for bare metal or various commercial and open source RTOSes. Despite the number of different platforms, CPU architectures and RTOSes out there, low level bring-up, BSP and driver development are rarely discussed in blogs and articles on the web. While this is hardly my first experience with the NXP i.MX 7, I’ll share in this article some of the important steps we take, writing from scratch, a bare metal environment for the i.MX 7 on the SABRE board. Porting most RTOSes would be similar. This already bulky article focuses on the A7 with the M4 left for a following article. For reference I’m using DS-5 with ARM Compiler 5 and a Keil ULINKPro D debug probe.
Continuing from the last post, this article explores features specific to early members of the ARM Cortex-A family such as the Cortex-A9. Namely the L2 cache and TLB lockdown features found in those processors. It’s important to note that those two features are not available in more recent 32 bits ARM processors such as the Cortex-A7. Newer cores have a simpler TLB, and most often than not an integrated L2 cache instead of the external L2 found on the A9. However, the Cortex-A9 is still a popular core, found on the Xilinx Zynq-7000 and NXP i.MX 6 SoCs to name a few.
In this article, I’ll explore interrupt latency of a Cortex-A9 under various scenarios — and yes, it’s still on the Zynq-7000, since I still have that board on my desk from the last two articles. An upcoming follow-up article will describe methods of improving worst case latency.
This is a continuation of the snickerdoodle adventure, following last week’s successful “hello world” , using Micrium’s µC/OS RTOS. In this series of articles, I’m exploring the capabilities of the snickerdoodle as a development platform for high performance real-time operating systems.
This time, I will be running an embedded file system on the snickerdoodle module, enabling non-volatile storage capabilities. The bare snickerdoodle module includes an SD card cage in addition to an on-board NOR flash. While it is possible to use the NOR flash, this post will focus on the SD card, which offers more versatility for development and prototyping.
What would make a better first post about embedded software than a hello world project on a brand-new development board. It’s the krtkl snickerdoodle I received with much excitement last week. In these next series of articles, I’m going to explore the capabilities of the snickerdoodle as a development platform for a high-performance real-time operating system. In this first article, I’ll run µC/OS, a commercial RTOS, on the snickerdoodle.
Before going any further, I think it’s important to mention that the snickerdoodle, with various optional base boards and accessories, can still be pre-ordered from Crowd Supply. Expected shipping date is around August.