Author: acassis

Sheding some (infrared) light on MLX90614

After implementing the MLX90614 driver for NuttX I noticed that although the write command to change the device I2C address in the EEPROM was reporting success, after the power cycle the new address was not working. Worst: even the previous address was not working.

Basically the device appears damaged and didn’t respond to any I2C command.

Then doing my research I discovered a Melexis document about SMBus communication:

In this document I noticed they are using the address 0x00 instead of the default 0x5a address. After modifying the driver to use the 0x00 address the device accepted the new command.

There are many discussing about this subject on Arduino and similar forum:

Note that someone discovered that using a brute force CRC approach eventually will work and everybody decided to copy it. Too bad guys!

The MLX90614 uses CRC8-CCITT standard to check if data are correct, so any CRC8-CCITT implementation will work, for example this one:

Now on NuttX you can call the mlx90614 example application to change the device’s I2C address this way: (changing from default 0x5a to 0x3a)

nsh> mlx90614 0x3a
Address 0x3a stored on your device!
Please do a power cycle and update the I2C board address!

Checking the CRC-8 PEC byte of MLX90614

I am creating a NuttX device driver for Melexis MLX90614 and it is a nice adventure.

First I downloaded the adafruit lib and tested it on Arduino Uno just to confirm the sensor was working, but I didn’t look the source code because I always prefer to read the datasheet and implement the driver from scratch.

All things fine, the mlxtest example worked correctly and I got the ambient temperature and the object temperature printed correctly.

Then I created the driver and decided to test it on STM32F103, but discovered that I2C_TRANSFER() for STM32F103 is broken. No problem, let to test it on STM32F4Discovery board:

nsh> dd if=/dev/thermo0 of=/dev/null bs=2 count=1
mlx90614_read_word: value[0]: 0xDF | value[1]: 0x3A | value[2]: 0xCF | ret: 0

Let see in the logic analyzer to confirm:

Very good! But how to check if CRC-8 PEC field (third received byte: 0xCF) is correct?

I found this nice online CRC calculator:

But putting all values as suggested in the datasheet didn’t work:

0x5A 0x06 0x5A 0xDF 0x3A
Result CRC value: 0x2F

Then just web searching for: MLX90614 PEC CRC-8 example

Returned me this thread:

The “thb” guy saved me:

“I haven’t checked your CRC implementation but there is a mistake in the MLX datasheet or at least it’s badly written. You have to include all the I2C frame’s data for the PEC’s calculation not just the replied data. For a read word command you have to include [SA_W, Command, SA_R, LSB, MSB] and for a write word command [SA_W, Command, LSB, MSB]. So, for their first example the calculation must be made on [ 0xB4, 0x07, 0xB5, 0xD2, 0x3A ] and not just on [ 0xD2, 0x3A ] and this way you get the expected 0x30.”

What this guy is saying is: we need to include all the bits of the Slave Address, the address needs to be seen as 8-bit including the the less significant bit Write or Read. So I2C Write at address 0x5A is seen as 0xB4 and I2C Read is seen as 0xB5 (pay attention at bits over the “5A” in the logic analyzer image above).

So, let to try his idea:

0xB4 0x06 0xB5 0xDF 0x3A
Result CRC value: 0xCF


Using coroutine on Lua

The Lua documentation about coroutine is not much clear and the example is not much useful. Fortunately I found an explanation how to use it and simplify the idea here:

sleep_awhile = function (period)
        os.execute("sleep "..period)

func_a = function()
        nnew = 0
        while true do
           nnew = nnew + 1
           print ("func_a ", nnew)
           print ("AGAIN ...")

func_b = function()
        count = 0
        while true do
           count = count + 1
           print ("func_b ", count)

-- ======= Main code =============

cor_a = coroutine.create(func_a)
cor_b = coroutine.create(func_b)

while true do
        itdidit,newcount = coroutine.resume(cor_a)
        print (newcount)
        itdidit = coroutine.resume(cor_b)

I hope it be useful for you too.


the moon… beautiful! oh yeah!

Today I decided to test the Lua (the programming language, it means Moon in Portuguese) with FLTK. There is a project called lua-fltk4lua.

Unfortunately the project doesn’t explain how to compile it from source code and it expects the developer uses the “luarocks” package manager to install it.

Although initially I was getting some issues like:

No rule to make target “moon/moon.h”
No rule to make target “compat-5.3/c-api/compat-5.3.h”

I figured out how to get it compiled and working easily, find the steps below:

$ sudo apt-get install lua5.2

$ sudo apt-get install liblua5.2-dev

$ sudo apt-get install libfltk1.3-dev

$ git clone

$ cd lua-fltk4lua

$ git clone moon

$ git clone compat-5.3

$ make

$ sudo make install

This is a nice Hello World to see it working, just create a hello.lua file with it:

local fl = require( "fltk4lua" )
local window = fl.Window( 340, 180, "Hello" )
local box = fl.Box( 20, 40, 300, 100, "Hello World!" ) = "FL_UP_BOX"
box.labelfont = "FL_HELVETICA_BOLD_ITALIC"
box.labelsize = 36
box.labeltype = "FL_SHADOW_LABEL"
window:show( arg )

And run:

$ lua hello.lua

Just it!

Running NuttX on LPCXpresso54628 OM13098

Today I tested NuttX running the LVGL demo on LPCXpresso54628.

Here you can find the steps needed to get it working.

First compile the firmware to create the nuttx.bin:

$ ./tools/ lpcxpresso-lpc54628/lvgl
$ make menuconfig
$ make

Now you can flash the firmware using JLinkExe on Linux.

You can use the LPC54608J512 even to flash the LPC54628:

$ sudo JLinkExe -if SWD -device LPC54608J512
SEGGER J-Link Commander V6.32h (Compiled Jul  5 2018 18:15:02)
DLL version V6.32h, compiled Jul  5 2018 18:14:58

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: 268006167
License(s): FlashBP, GDB

Type "connect" to establish a target connection, '?' for help

Run “connect” command:

J-Link> connect
Specify target interface speed [kHz]. : 4000 kHz
Device "LPC54608J512" selected.
Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
Cortex-M4 identified.

Finally flash nuttx.bin using the loadbin command:

J-Link>loadbin ./nuttx.bin 0
Halting CPU for downloading file.
Downloading file [./nuttx.bin]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (360448 bytes)
J-Link: Flash download: Total time needed: 3.314s (Prepare: 0.058s, Compare: 0.009s, Erase: 0.991s, Program: 2.245s, Verify: 0.005s, Restore: 0.003s)
J-Link> exit

Reset the board and you should see the touchscreen calibration screen.

And then: