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 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.
A bootloader on a microcontroller is a very useful thing. It allows me to update the firmware in the field if necessary. There are many ways to use and make a bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“). But such a bootloader needs some space in FLASH, plus it needs to be programmed first on a blank device, so a JTAG programmer is needed. That’s why vendors have started including a ROM bootloader into their devices: the microcontroller comes out of the factory with a bootloader in FLASH. So instead writing my bootloader, I can use the one in the ROM.
FRDM-KL03Z with ROM Bootloader
And as with everything, there are pros and cons of that approach.
University research projects can be a lot fun, and are very challenging the same time. The good thing is that there is always someting new to learn :-).
This week-end I was working on my Internet of Things (IoT) project, based on a Freescale KL15Z and a nRF24L01+ transceiver. In essence it is a wireless data logger. For this, I only can afford a few micro amps consumed by the whole board over an extended period of time. I mean 21 micro amps for running a whole board with sensor, EEPROM, wireless transceiver, operating system and an ARM Cortex-M0+ ready to crunch numbers at 20 MHz 🙂
21 micro amps for wireless sensor node (when not sending)
I probably would have missed the fact that Freescale has released a new Freedom board, if I would not have visited my local distributor site to order a replacement for one of my first FRDM-KL25Z boards. So surprise, surprise: there is a new Freedom board: the FRDM-KL26Z!
So instead ordering again a FRDM-KL25Z, I decided to order that new FRDM-KL26Z instead. And it arrived right before Christmas, and now I had time to check it out. Nope, I did *not* use it as a blinking gadget on a Christmas tree, even if that would have been a nice idea ;-).
The good thing with the internet is: it allows engineers to collaborate. And here is an example: Marc is a reader of this blog had a problem with the I2C hardware of a Freescale Kinetis ARM microcontroller. In his case, the I2C bus could be stuck, and there seems no way to reset it with the I2C hardware on the microcontroller. So a solution would be to reset it with software instead.
If you are a frequent reader of this blog, then you know: I’m a big fan of Processor Expert components. While there are many Processor Expert components delivered with CodeWarrior, it lacks many components and device drivers beside of the normal on-chip peripherals. But value gets added to an embedded project with all the external devices, sensors and actuators. That’s why I have created many more components which are available on my GitHub site. Readers of this blog have asked several times to create a tutorial on how to create a Processor Expert component. So why not working on that on a long Easter weekend full of cold rain and snow?
So here we go: a tutorial how to create a Processor Expert component for the MMA8451Q accelerometer found on the FRDM-KL25Z board:
The CSI is one of my favorite crime drama television series: not because it reflects the true reality, but because it is fun watching how they always find new ways how to investigate a crime scene with ‘close to reality’ tools. Real CSI is different: you only do a small part of the investigation chain. As for myself, I’m engaged in a research project at the university to develop hardware and software for crime scene investigation :-).
One area of that research project is to retrieve and data from credit card (ATM) skimming devices: these are devices are attached or inserted into credit or debit card machines and ‘skim’ the card information and the PIN code used. With that information, it is possible to clone a credit card for credit card fraud. Such devices are a big problem, and newer devices are very hard to spot. Simply ‘google’ for pictures for “skimming device” and you will get an idea of the diversity and madness of such devices :-(.
I really hatethis kind of stuff: I know it should work, but it does not. I’m loosing a lot of time (hours, days, even weeks) to track it down to the root cause. Yes, I create my own bugs. Yes, there are bugs in tools, sources, libraries and components. But what many might not believe: there are bugs in silicon too :-(. If you do not believe, here is one: there is a hardware I2C problem on the KL25Z used on the Freedom board. It worked in one project, but not in another.
❗ The silicon bug described here is present on many Kinetis devices, not only the KL25Z!
Logic Analyzer attached to the FRDM-KL25Z board
So if you are facing a problem where you read 0xFF or wrong values from the I2C bus with the KL25Z, here is probably why (and how to workaround it). The problem showed up with a modified version of the Freedom Accelerometer tutorial….
I’m working with the I2C bus recently a lot. I’m using it in a project to reverse-engineering skimming (credit card fraud) devices. I needed to improve one of my applications for the lecture classes where a MCF52259 is communicating with a TWR-LCD display over I2C. And I want to add RTC (Real-Time-Clock) capabilities to my Arduino Data Logger Shield which requires I2C.
The same time I want to have things working with ARM Cortex-M4 and M0+ devices. And here the challenge started: using the I2C_LDD (Logical Device Driver) Processor Expert components for the ARM Kinetis devices is definitely not simple and easy. I want to use my software compatible for both the ARM cores and say for S08 and ColdFire cores. So what I ended up is to write a ‘generic’ I2C driver on top of the low level Processor Expert components: named GenericI2C.
One success factor of the Arduino platform is the broad availability so-called ‘shields’: hardware plugin-modules which extend the capability of platform. Shieldlist.org currently lists 288 different shields available! Clearly, Freescale wants to benefit from that ecosystem with the Freedom FRDM-KL25Z board which features Arduino compatible headers. Time to use the Freedom board with an Arduino shield :-).
The Freescale ColdFire V2 (MCF52259) is a great communication device: an embedded Processor like a Swiss Army Knife: Great peripherals, USB and Ethernet interface, a lot of flash application space and up to 64 KByte of RAM. I’m using that core in many projects, and there is great community support for it with boards and software. Unfortunately Freescale somehow provides Processor Expert support only half way for it. Support for the I2C bus is missing :-(.