mDot Serial Function

[Szymon Zieba]

Hi,

I am attempting to set up a serial connection to the UART Pins; SERIAL_TX and SERIAL_RX, using the Serial function of mBed. The program compiles fine on the computer however once loaded onto the mDot, I receive an RTX error code: 0x00000004. I have tried this on multiple mDots getting the same result. What should I do?
In case you need to know, I am setting the baud rate at 115200 for this Serial connection.

Regards

[Szymon Zieba]

As an additional, separate question, is it possible to update the mDot remotely, Such as updating the firmware or changing the programming via OTA connection?

[Mike Fiore]

Syzmon,

WRT your first question:

RTX error code 4 is timer overflow. The error codes are defined in mbed-os/rtos/TARGET_CORTEX_M/RTX_Config.h. The only place where this error can be returned is from the systick isr (sysTimerTick) in rtx/TARGET_CORTEX_M/rt_CMSIS.c. I haven’t seen this show up in practice before. Can you share some information about the application that is causing this error? Is there some portion of your code that is running in a tight loop or starving other threads in some way?

WRT your second question:

We don’t currently support OTA firmware updates for the mDot, but it does have a bootloader that will flash new firmware if it finds new firmware in the filesystem on the external SPI flash. We have a writeup about updating firmware using the bootloader on mbed.

https://developer.mbed.org/teams/MultiTech/wiki/updating-firmware-using-MTS-bootloader

You’ll be interested in the “Updating Firmware from User Applications” section. You’ll have to get the FW to the mDot via serial, LoRa, etc, and put it into the filesystem using the mDot filesystem API. Then you’ll call

bool moveUserFileToFirmwareUpgrade(const char* file);

to give the file the proper name. Finally, initiate a system reset

void resetCpu();

On startup, the bootloader will detect the new firmware and update the application. The update should take ~15 seconds, but this will vary depending on the size of the new application.

Hope this helps!

Cheers,

Mike

[Szymon Zieba]

Thank you for your answer regarding OTA updates. I will take a read through. For the Serial Code, here is the full thing, minus code for connecting to the LoRa server:

#include “mbed.h”
#include “mDot.h”
#include “MTSLog.h”
#include “MTSText.h”
#include <string>
#include <vector>
#include <algorithm>
#include <bitset>
#include <stdlib.h>

Serial connect(SERIAL_TX, SERIAL_RX, 115200);

int main() {
int32_t ret;
mDot* dot;
std::vector<uint8_t> data;

while (true) {
char mystring;
if (connect.readable() == 1 && connect.writeable() == 1) {
connect.puts(“Please enter a character: \n”);
mystring = (char) connect.getc();
} else {
mystring = 0x00;
}

if (mystring != 0x00) {
logInfo(“mystring = %c”, mystring);
std::string msg(1,mystring);

// format data for sending to the gateway
for (std::string::iterator it = msg.begin(); it != msg.end(); it++)
data.push_back((uint8_t) *it);
}

// in the 868 (EU) frequency band, we need to wait until another channel is available before transmitting again
osDelay(std::max((uint32_t)5000, (uint32_t)dot->getNextTxMs()));
}

return 0;
}

I can get the Serial connection to work if I change to RawSerial, but it would be good to know whats wrong with the normal Serial Connection.

Library wise I am using libmDot-dev-mbed5 rev:75:60e21ba8350a, mbed-rtos rev:123:58563e6cba1e, and mbed.bld rev:130:d75b3fe1f5cb.

[Szymon Zieba]

Hi Mike,

I have changed the libraries so that I am now using mbed-os and now the Serial function is working. I am not sure what happened as I haven’t changed anything code wise.

Regarding the usage of the bootloader, I am a little confused as to how I would transfer a file onto the mDot via LoRa for example? Should I be setting up an SPISlave on the LoRa for reading any incoming files?

Thank you for your help

[Mike Fiore]

Syzmon,

The libmDot-mbed5 libraries aren’t compatible with mbed & mbed-rtos and must be used with mbed-os. I think that was the issue all along.

To get the new FW to the mDot, you would need something on the server side that queues up chunks of the new firmware to be transmitted down the mDot. The mDot could keep sending empty packets so it gets the new FW faster. You could also use class C mode and basically have the network server stream the FW to the mDot. The mDot would need to put the firmware back together and store it in the filesystem on the external SPI flash. You’ll probably want some kind of application level protocol in order to successfully transfer the file.

Once you’ve got the full new FW on the mDot, rename the file and reset like I mentioned earlier and the bootloader will take care of the rest.

Hope this helps.

Cheers,

Mike

• This reply was modified 7 years, 5 months ago by Mike Fiore.
• This reply was modified 7 years, 5 months ago by Mike Fiore.

[Author]

Posts