TFTP boot loader for Simplecortex is working

The problems I had with the TFTP boot loader last week are solved!

Last weekend I discovered that the InterruptTimer_CoIDE example project I used from the Simplecortex repo wasnt’t working that well as I thought. When I started with the TFTP boot loader, one of the first things I did was running that example unmodified frm the normal start address. I saw all the LEDs blinking, so there was no reason to think that something was wrong.  Then, last Saturday I read this post on the Simplecortex forum. Apparently timer interrupt 3 wasn’t doing what it should.. hmm, in my case, timer 3 was the only one that did work in TFTP mode – there must be some link between the 2 issues!

And I was right – after updating the InterruptTimer_CoIDE example from the repo, all the LEDs were still all blinking in non-TFTP mode of course, but in TFTP mode none of the 4 LEDs were blinking! That may sound bad but it isn’t; I’d rather have 4 timers not working than 3 that don’t and 1 that does 😉

Cause now I had a consistent behavior and not something completely inexplicable; now the user code didn’t function ‘a bit’ – no, now it didn’t function at all! That sounds like a better starting point to find the error. Somehow I had the feeling that the  interrupt vectors were wrong; but why?

The mistake I made was that I had a completely wrong perception of what was going on when the TFTP boot loader jumped to the user code:

/* Change the Vector Table to the USER_FLASH_START
in case the user application uses interrupts */

// Load contents of second word of user flash - the
// reset handler address in the applications
// vector table
p = (unsigned *)(FLASH_START_ADDR + 4);

// Set user_code_entry to be the address
// contained in that second word
// of user flash
user_code_entry = (void *) *p;

// Jump to user application

The vector table is set to the right address (line 3) and the user code is called.


I don’t know why, but somehow I had the (wrong) idea that the user_code_entry() call jumped directly to main() in the user code – and this idée fixe withheld me from finding the solution, which was relatively simple as I found out later… Willem, someone I know from the Domoticaforum tried to help me and mentioned I should change the SystemInit() in system_LPC17xx.c. Well, the only thing I could think of was the following:

void SystemInit (void)


  //  Set Vector table offset value
  #if (__RAM_MODE__==1)
    SCB->VTOR  = 0x10000000 & 0x3FFFFF80;
    SCB->VTOR  = 0x00000000 & 0x3FFFFF80;

This code sets the vector table back to the value needed for ‘normal’ operation, where the user code starts at 0x00000000. But… why bother, the user code doesn’t come here at all, right? After Willem mentioned SystemInit() a second time I decided to give it a try although I still didn’t think it would help… WRONG!

The moment I saw all the LEDs blinking at a different rate, suddenly 2 words in the comments caught my attention: reset handler.

Of course, how could I be so blind… the user_code_entry() call mentioned earlier doesn’t call main(), but the reset handler – so this effectively runs the same code as if the Simplecortex has been reset! And the default reset handler routine contains a call to SystemInit(), so the effect was that the vector table was overwritten by the user code…



TFTP Bootloader for Simplecortex

About a week ago a topic on the LPCXpresso forum was brought to my attention. A TFTP boot loader, now that’s something I’d really like to have!

Whenever the MCU is (re-)started the boot loader will try to download a specific file from a specific TFTP server. If the boot loader can successfully download a valid file, it will flash the MCU and jump to the ‘user code’ at a predefined address.

So I mentioned this TFTP boot loader on the Simplecortex forum to see if anyone had already tried it. Nope, I was the 1st one, but one of the forum admins was so kind to have a look and created a project for it.

Lets see if I can get this working…

Setting up the environment was easy. I created a small project that uses interrupts to blink LEDs 6 to 9 at different intervals. In the project configuration I had to set the start address to a different value and decrease the size as well:

User code project settings

This is necessary so that the ‘user code’ won’t be flashed from address 0x00000000 which would result in the boot loader being overwritten – the start address had to be set to 0x0010000 (64 kb). This way the TFTP boot loader (which does start at 0x00000000) will stay intact and the ‘user code’ will be in the flash memory after the boot loader.

I copied the resulting .bin file to my TFTP server, flashed a Simplecortex with the TFTP boot loader and watched …

TFTP boot loader downloading file

OK, the first part works fine; I saw the file being downloaded by the Simplecortex. But that was all… nothing happened!

The boot loader has a built-in diagnostic option of a LED that blinks a number of times, depending on the kind of problem it encounters. LEDs see what this LED can reveal…

I changed the LED port to 0.26 (the easiest/closest pin to 3.3V) and I got 1 blink, meaning that the download was successful but the user code was invalid. Reading the code that validated the user code, I saw some sort of checksum being calculated. Ah, yes, I saw a checksum being mentioned somewhere. But I don’t have a ‘checksum’ program? I searched the web and I found a ‘lpcrc’ tool that was able to calculate the checksum of a .bin file and write that checksum into the .bin file: 4 bytes, starting at position 0x1c. Time for a post-build script:

Post build script

lpcrc Debugbin%1.bin
copy Debugbin%1.bin c:TFTP-Roottest.bin

Now the user code .bin file contained the correct checksum; retry!

New tests confirmed that the boot loader does jump to the user code at address 0x00010000 now, but the user code runs ‘crippled’ – where it should toggle LEDs 6..9 each with its own interval, only LED9 is working…. and why? Dunno yet… something that needs to be reinitialized, reset, ??? A big mystery…

Interrupts maybe? The user code makes use of 4 TIMER interrupts; only TIMER3 seems to be working? I hope I can find out what is going wrong here…

#include "LPC17xx.h"
#include "lpc_types.h"
#include "GPIO.h"
#include "timer.h"

uint32_t toggle = 1;
uint32_t toggle1 = 1;
uint32_t toggle2 = 1;
uint32_t toggle3 = 1;

int main(void)
  init_timer(0, 15000000);
  init_timer(1, 30000000);
  init_timer(2, 60000000);
  init_timer(3, 120000000);
  GPIOSetDir(1, 18, 1);GPIOSetValue(1, 18, toggle);   // LED6
  GPIOSetDir(1, 19, 1);GPIOSetValue(1, 19, toggle1);  // LED7
  GPIOSetDir(1, 24, 1);GPIOSetValue(1, 24, toggle2);  // LED8
  GPIOSetDir(1, 25, 1);GPIOSetValue(1, 25, toggle3);  // LED9
void TIMER0_IRQHandler (void){
  toggle = ~toggle;
  GPIOSetValue(1, 18, toggle);
void TIMER1_IRQHandler (void){
  toggle1 = ~toggle1;
  GPIOSetValue(1, 19, toggle1);
void TIMER2_IRQHandler (void){
  toggle2 = ~toggle2;
  GPIOSetValue(1, 24, toggle2);
void TIMER3_IRQHandler (void){
  toggle3 = ~toggle3;
  GPIOSetValue(1, 25, toggle3);

Smart meter online

After 3 weeks, finally the end result came dangerously close 😉

Every time I finish something new and the time comes to actually start using it, I get excited – will it work? Cause testing in the office is something completely different than seeing real live data coming in! (yep, I forgot to check if I still had a free connection on the switch in the fuse box…)

Simplecortex with Proto Shield

The Simplecortex had been running without any problems during the last 2 days so it was time for the last part: inverting the P1 signal before it arrives at the Simplecortex UART0. I had an old Arduino Proto Shield laying around and put an 7470 inverter on top.

The ‘receiving end’ i.e. my Domotica system is ready – which consisted of adding an MQTT client to it and making sure it subscribes to the necessary topics. Just 2 more wires that needed to be soldered and I could hook up the Simplecortex to my smart meter… couldn’t wait!

And this evening I decided to remove the laptop that was logging the P1 data to a file from day 1 and replaced it with the contraption you see below.

Smart meter online!

And this is what it publishes (output from a MQTT subscriber):

/P1/powerusage1 00311.543
/P1/powerusage2 00158.107
/P1/powerdeliv1 00000.000
/P1/powerdeliv2 00000.000
/P1/tariff 0001
/P1/powerusagec 0001.88
/P1/powerdelivc 0000.00
/P1/gasusage 00027.758


The hardest most exciting part was developing the code in C for the Simplecortex. For my work but also at home I see a lot of code, in all kinds of languages and I can follow what the code should do – but getting started with writing my own code in a language which I hadn’t really used before took me some time – I just kept on changing things because I was not satisfied. Now I am (thanks, JC!), although there are still some minor things I have to work on. But those are not necessary for now; I can flash the Simplecortex later, when everything is completely finished software-wise.

Now I can start logging gas usage again and I can stop using my DIN rail mounted KWh-meter with S0 output which I used for power usage (but not before I’ve had a chance to compare it with the smart meter, though). Source code will be available on GitHub soon (account has already been made) .

Next project that will be handled in a similar way: the Opentherm Gateway! For that one the Simplecortex needs to be able to subscribe as well!

Edit: the P1_Publisher project has been committed to Github some moments ago:


Publishing smart meter P1 data

Got it!

I just had to know whether my Simplecortex code was any good; it would be nice to see some real results instead of all the test results that were created along the way. The code was in a ‘workable’ state so I was ready to test if I could turn the Simplecortex into a MQTT client and publish the relevant smart meter P1 data.

I already downloaded Mosquitto somewhere in July, tried some simple (and successful) tests with a Delphi MQTT Client, but now it was time for the real thing. The Simplecortex was already running when I started the mosquitto server from a command line and I saw the Simplecortex connecting to the mosquitto server (great, auto connect works):

Mosquitto server

No timeouts, disconnects or any other thing that looked suspicious; so lets see if the Simplecortex is actually publishing something. For that I started a mosquitto client from another command prompt to subscribe to the topic for the current power usage:

Mosquitto client

Yes! Every 10 seconds I see the current power usage being updated;  cool, it works!

The biggest hurdle I had to take was the fact that the uIP API doesn’t allow you to just send outgoing data when/where you’d like to – no, the uIP API calls the application (a C function) when data is received, data has been delivered to the other end, when a new connection has been set up, and when data has to be sent. Therefore I had to use a sort of publish queue to store the MQTT publish messages until the uIP API allowed the application (the MQTT client on the Simplecortex) to actually send the data to the MQTT broker.  But the uIP stack had some good examples of which I gladly made use of 🙂

Does this mean I’m finished? Not yet.. There are still some things I’m not happy about; the way some things are setup in code right now. Ping for example, uses a hardware timer which throws an interrupt way too often for an interval of (now) 30 seconds. And the UART is being read in main(); I want that nicely tucked away too. And there are some other things that still need to be improved, all caused by my lack of C knowledge – while developing code for part B, I realize I could better have coded part A in a different way (and better)!

But for now, I’m going to sit back, relax and watch it working 🙂

Smart meter P1 project is doing fine

Surprise! Today I saw the following:



Yep, this means the gas usage is working too now! I called Liander last Monday to tell them my gas usage still wasn’t working and that I still got all zeroes. I had a bit of a problem explaining what I was doing (dunno why…), but at the end of the conversation I got the feeling my problem was taken seriously. That same day (late in the evening, as I found out today) the gas usage suddenly popped up; good, very good!

This evening I also managed to get the Simplecortex to automatically recover from lost connections. This is very very important because not being able to do that automatically would be a real show-stopper for me. Just think of it, that you would have to press the reset button after network problems or any other reason a connection has to be re-established; sounds horrible!

This weekend I’m going to have a look at 2 options to invert the P1 signal: a 7404 inverter IC or a BS170 transistor. These 2 options enable me to connect the cable from the P1 port directly to the UART of the Simplecortex; no additional components needed. I read about that last option (BS170) here and I just couldn’t resist ordering the parts for both options to see how they both work. Just out of curiosity…

And I’ll have to modify the UART library a bit cause as this library is now, it only supports 8 bits, no parity and 1 stopbit.

Next week will probably be dominated by adding MQTT Publishing support to the Simplecortex project.

This means that if all goes well,  at the end of next week I can install the Simplecortex near the smart meter and start subscribing to the smart meter topics!

Processing the smart meter data (3)

Well, 2 days later and I’m getting somewhere 🙂

First of all, I must have been drunk when I said the Simplecortex was sending its data with an interval of 200 ms – no, that’s the timer resolution of my logger! The simplecortex sends a packet each time a newline (or line feed, LF) is received from the P1 port. So that’s solved.

First thing on the todo list was parsing the P1 data and extracting the numbers I want to receive in my system:

#define P1PU1  "1-0:1.8.1"      // total power usage normal tariff
#define P1PU2  "1-0:1.8.2"      // total power usage low tariff
#define P1PD1  "1-0:2.8.1"	// total delivered power normal tariff
#define P1PD2  "1-0:2.8.2"	// total delivered power low tariff
#define P1TIP  "0-0:96.14.0"    // tariff indicator power
#define P1PUC  "1-0:1.7.0"	// current power usage
#define P1PDC  "1-0:2.7.0"	// current power delivery
#define P1GTS  "0-1:24.3.0"	// timestamp gas usage sample

A routine was made to check each received line for the occurrence of the above-mentioned OBIS references (identification codes for data in DLMS/COSEM compliant metering equipment), get the value out of the received line and store the result in a buffer:

else if(strncmp(P1PU1, line, 9) == 0)
  strncpy(value, line+10, 9);
  sendbuf("powertotalN;", value);

… and another routine that’s being called whenever the application is allowed (by the uIP TCP/IP stack) to send the data over to the other side of the connection. And this is another intermediate result, received by my domotica system:

22:41:54.406  TCP < powertotalN;00003.725
22:41:54.406  TCP < powertotalL;00000.000
22:41:54.406  TCP < powerdelivN;00000.000
22:41:54.406  TCP < powerdelivL;00000.000
22:41:54.406  TCP < powertariff;0001
22:41:54.506  TCP < powercurrent;0000.96
22:41:54.506  TCP < delivcurrent;0000.00
22:41:54.707  TCP < gastimestamp;120808010000
22:41:54.707  TCP < gasusage;00000000
22:42:04.722  TCP < powertotalN;00003.728
22:42:04.722  TCP < powertotalL;00000.000
22:42:04.842  TCP < powerdelivN;00000.000
22:42:04.842  TCP < powerdelivL;00000.000
22:42:04.842  TCP < powertariff;0001
22:42:04.842  TCP < powercurrent;0000.97
22:42:04.842  TCP < delivcurrent;0000.00
22:42:05.043  TCP < gastimestamp;120808010000
22:42:05.243  TCP < gasusage;00000000

That’s much better than what I had 2 days ago; well 4 hours ago actually, cause time is limited and I’m also learning more and more about C while working on this.

Next step: sending this data as payload in a MQTT Publish message! The protocol is not so hard in its simplest form and I’ve got working Delphi MQTT code, so this should not be a problem.

In the meantime some parts have arrived: an enclosure for the simplecortex, 7404 hex inverters and transistors to invert the P1 signal.


Processing the smart meter data (2)

Today I made some progress on processing the smart meter data with a SimpleCortex.

I started collecting the P1 data from our smart meter from the first day it was installed. A laptop, an RX-inverted USB cable and HyperTerminal take care of that for almost a week now.

Logging P1 smart meter data with HyperTerminal Now it was time to do something with the data I logged (currently 25 MB in size).

For that, I needed to create a test setup, with which I could simulate that the SimpleCortex was directly connected to the Smart meters P1 port.

Well, that was not so hard; I wrote a quick & dirty VB.Net tool that mimics the P1 ports behaviour, by reading the logged data and writing it to a Serial port.

This Serial Port is a USB-BUB connected to  UART0 of the SimpleCortex:

Feeding the SimpleCortex with smart meter data

Now I only needed a receiver for what the Simplecortex wants to send; for that I used a small Delphi app with a Indy IdTCPServer component – this logs everything it receives to a file, so I can easily monitor what’s being received.

With the VB.Net “P1 feeder”, the USB-BUB and the Delphi TCP server app I can now code, flash, test & debug with the Simplecortex right beside me in my office; I think I’ll need it, cause I’ve still got a long way to go.

Now that I had setup the right test-environment I could start with writing the code for the Simplecortex. If only I could get some sort of ‘Hello world’ example for the uIP TCP/IP stack to get me going – the Simplecortex webserver example looked like overkill; too much to learn at once, I needed something simpler to start with. Mark, who commented on an earlier post about the Simplecortex, was so kind to help me out and provided me with an example of a project that echoed the TCP data it received; and that was all I needed – suddenly it was clear to me how I should start.

And here it is, the output that’s being received from the SimpleCortex:

15:34:11.078  TCP < !
15:34:20.952  TCP < /ISk52ME382-1003
15:34:20.952  TCP < 137
15:34:21.112  TCP < 0-0:96.1.1(4B414C37444035313039373537343132)
15:34:21.112  TCP < 1-0:1.8.1(00002.368*kWh)
15:34:21.112  TCP < 1-0:1.8.2(00000.000*kWh)
15:34:21.112  TCP < 1-0:2.8.1(00000.000*kWh)
15:34:21.112  TCP < 1-0:2.8.2(00000.000*kWh)
15:34:21.312  TCP < 0-0:96.14.0(0001)
15:34:21.312  TCP < 1-0:1.7.0(0000.88*kW)
15:34:21.312  TCP < 1-0:2.7.0(0000.00*kW)
15:34:21.312  TCP < 0-0:17.0.0(0999.00*kW)
15:34:21.312  TCP < 0-0:96.3.10(1)
15:34:21.312  TCP < 0-0:96.13.1()
15:34:21.312  TCP < 0-0:96.13.0()
15:34:21.312  TCP < 0-1:24.1.0(3)
15:34:21.312  TCP < 0-1:96.1.0(3238303131303031344439323034343132)
15:34:21.513  TCP < 0-1:24.3.0(120807230000)(00)(60)(1)(0-1:24.2.1)()
15:34:21.513  TCP < (00000000)
15:34:21.513  TCP < 0-1:24.4.0(1)
15:34:21.513  TCP < !

For now, the only thing the Simplecortex does is waiting for data on UART0 and transmitting the data it received to the IP address of my PC. Sounds like a simple task, and it was; I was actually surprised with how fast I finished this first step.

But as I said: I still have a long way to go, cause this is still on my todo-list for this project:

  • Parse the incoming P1 data and collect the data I need (power usages, gas usage)
  • Act as a MQTT client and publish the collected data;
  • Being able to handle 7-E-1 with the UART instead of 8-N-1
  • Automatically reconnect when the connection fails for whatever reason;

And of course there are some technical issues I don’t understand fully yet; one of them being the interval with which the Simplecortex seems to send the data – every 200 ms? Strange.

So there’s still a lot to do, but the preliminary results make me happy and give me confidence for a good end result 🙂

First look at the simplecortex

Today a Dutch product, manufactured by Iteadstudio arrived – the simplecortex. I ‘discovered‘ this board just before holidays started, so it took some time before I could really hold one in my hands. Now I can.

The board comes with a mini CD with several tutorials on how to get started, example code and a CoIDE tutorial. It looks like the contents of this CD has been produced about 4 months ago, so I decided to download the libraries and the rest I needed to get going from the simplecortex website, especially since it’s such a new product where it’s not uncommon that libraries on the website are newer than on the CD.

The board looks very nice – I think that lots of Arduino shields will fit even better on the simplecortex than on a Arduino Duemilanove with its big USB socket! The only thing I’m missing are mounting holes. And a micro SD card inserted into the slot sticks out – maybe this was done on purpose, but I would personally prefer the micro SD card to stay within the PCB dimensions of the simplecortex.

I had already installed CoCenter & CoIDE, so all I had to do was install the USB drivers and I was good to go. After a first ‘blinking LED‘ example to test if everything was installed correctly and working like it should, I decided to take a deep breath and start trying!

First thing I noticed is that the CoIDE is a big improvement compared to the Arduino IDE:

Just hover over a function call and you can see the code behind it – and if it doesn’t fit in the popup, the F2 key enables you to scroll through it; Esc makes the popup disappear again.

Flashing the simplecortex is also amazingly fast compared to the Arduino platform,  wow. And I haven’t even scratched the surface yet, so there are probably many more surprises to come 😉

I bought a TFT LCD with Touch some months ago and I thought it would be a nice exercise to get this LCD working with the Arduino pin compatible simplecortex, even though I know almost nothing about the simplecortex and its components yet. I saw a simplecortex Graphics LCD library, but unfortunately this library could only be used with TFT LCD shields that use different pins than the TFT LCD I have here. So now I’m trying to adapt this library to my LCD; I think I’ll have a lot more to tell when I’ve accomplished that.

And after that.. who knows, what other tasks the simplecortex will get in my Home Automation system!


Last saturday an article in the newspaper caught my attention. The story was about 3 students that made their own development board: the Simplecortex, built around the LPC1769 from NXP, a ARM Cortex-M3 based microcontroller running @ 120 MHz with 512KB flash, 64KB RAM, MicroSD slot, 8 x 12bit ADC, 10bit DAC, SPI, 6 xPWM, 3 x I2C, 4 x UART, USB-host and Ethernet on board (did I miss something?)

Impressive… this could be the ideal board for projects where the Arduino-like boards can’t manage and a Raspberry Pi is overkill (I can do without Linux on board for those things I want to do).


Here’s a comparison with 2 Arduino boards:

Simplecortex compared to Arduinos

Furthermore, the Simplecortex is Arduino pin compatible.

As development environment the free CoIDE from CooCox is used. This IDE supports debugging and lots of other features not found in the Arduino IDE but which are very welcome 😉

And last but not least, you’re not left in the dark after buying the Simplecortex – the website of the company that developed the board contains information on how to get started, there are libraries and examples you can download and there’s a forum. Sounds good to me, good enough to buy & try one!