Development Blog

Firmware v7.01R013 Released

Feb 21, 2019



v7.01 is up to release 13. This currently only has a build for the new C5 PCB.

Amongst the updates are a new storage area for inbound telephone numbers and time details

Significantly we've moved the status message storage area to the user memory. This means we can maintain a protected area for addresses 0x0000 to 0x4000.

The server can never read or write to these pages (0-7). We have also removed the ability for the remote update code to write over address 0x1F00 to 0x1FFF which is where the APN is stored


toBrowser Webpages

Feb 21, 2019

events.php, status.php



The events page has now been debugged.




This page is now active but requires firmware v7.01R013 or greater

toBrowser Webpages

Feb 20, 2019

e.php, c.php



This page has been created for the emergency call intercoms




This page has been created as the main interface page for the C5 PCB. There will be specific pages created for access control and alarm dialler applications in the future

toBrowser Webpages

Feb 14, 2019

events.php, status.php



The events page has now been complete. It is pending a debug of the GotRAM routine which copies text data from the remote PCB RAM to the log database

Currently this just shows the command to get data from RAM i.e. %Rllllbb where llll is address and bb is count




This page provides a means of changing the status message the device sends when you text it 'status'

There are switch characters activated by ~. So ~1 gives the voltage on channel 1. The more complicated ones give the pedge and RLYx status and other parameters

It means the user can customise the message after shipping. We have a similar page in development for the user commands - that will be fun!

Firmware v7.01 R012

Feb 14, 2019

Release 12 of v7.01 firmware.

Major developments described below:


No real bugs this time. Some changes to the IoT mode. There is now an EETESTED EEPROM memory which forces a web connection before testing.

Port to C5 PCB and implementation of the extended number log for the C5 model


Firmware v7.01 R010

Feb 01, 2019

Release 10 of v7.01 firmware.

Major developments and bug fixes described below:


Remote firmware updates are done by the server copying the firmware to the upper pages of the memory of the chip. Once uploading has completed, the chip copies this to the lower part of the memory where it can run

When copying the chip requires two bytes, 0x55 and 0xAA, to be written to the NVMCON2 register to enable access to the program memory. The latest version of the firmware requires the remote server to write these values to the RAM to ensure it cannot happen by accident during normal running.


During startup, the modem tells the chip when it is 'Call Ready'. This needs to be handled correctly by the chip and the word 'call' is also used to add call numbers. A paging issue on previous releases meant it was possible this could cause a reset which potentially could create a loop.


Paging issues were causing the IMEI number to be re-acquired each time a message was forwarded. There was no negative side effect but it caused an unnecessary read of the IMEI number.

'+' missing from numbers

Jan 27, 2019

Certain types of numbers entered on contacts.php would lose the '+' sign when the number was saved to the database for example:

+447123456789 would become 447123456789

This was due to a regular expression mistake added to the SaveContacts.php page a couple of weeks ago

$number = preg_replace("/[^0-9,.]/", "", $number);

Should have been:

$number = preg_replace("/[^0-9+]/", "", $number);

Firmware v7.01 R008

Jan 27, 2019

We have another release of v7 firmware.

The major issues and features are described below:


Stack overflow bug – in the send_text8 subroutine we had a goto clear_list_controls instead of return with clear_list_controls scheduled (send_stage = 1). Schoolboy error. I’m not sure when it was first written into the firmware but I looked back to v5.19R008 and it was in there back then. We didn’t really have too many sequential calls to this subroutine back then as the firmware was much simpler so the occasional stack overflow was captured by a reset. Not now though. After 10 messages we’d get a stack overflow reset. It would drop off the web for a short time etc…

Better trace code – We’ve improved the trace function around the event adding function. Now we log the event in the trace and then log the pointer value. For example:

84D bra SEND_OK

84E Event 43

84F wptr 04

850 send_chip_event


wptr and current pointer out of sync – this has now been tested for a complete reset and up to 100 events. There was the potential for a reset to cause multiple email events as witnessed this week.

We wont push an update for this as they're recoverable and not critical errors


Keeping users up-to-date with development work on

Popular Post

Contact Us

If you would like to see a feature added or have found a bug let the developers know directly