MultiTech's official mbed team.

Building MultiTech Dot-Examples with Mbed CLI

13 Apr 2018

Hi,

I've recently started looking at LoRa modules and Mbed as the company I work for considers development of an IoT device.

Yesterday I started looking more closely at the MultiConnect xDot as it has some clear advantages over the alternatives.

I thought downloading and building the Dot-Examples with the Mbed CLI would be a good place to start. Unfortunately it took me a bit longer than I was expecting and found other people asking similar questions.

My problem seemed to be not initially understanding the significance of the Mbed OS version used to build the library. I incorrectly thought mbed-os.lib in Dot-Examples did what was needed.

This is what worked for me:

mbed import https://os.mbed.com/teams/MultiTech/code/Dot-Examples/
cd mbed-os
git checkout mbed-os-5.7
mbed update
cd ..
mbed add https://os.mbed.com/teams/MultiTech/code/libxDot-dev-mbed5/
mbed compile -m XDOT_L151CC -t GCC_ARM

This changes mbed-os.lib.

I haven't got a dev board yet so I don't know that the examples actually run.

I used mbed-os-5.7 because the latest libxDot-dev-mbed5 commit message said "mbed-os revision mbed-os-5.7.7".

Without doing some research I'm not sure if the GCC Arm tools version is significant. I tried "6 2017-q2-update" and "7 2017-q4-major" and the build succeeded in both cases.

HTH, Matt

16 Apr 2018

I now realise that I didn't have to do the git checkout explicitly and that this is explained in the Dot-Examples\README.

What I should have done was mbed update mbed-os-5.7.

23 Oct 2018

Behavior is related to option switch passed to the gcc compiler If the debug option is selected among the switches passed to the compiler via debug.jason are -DMBED_TRAP_ERRORS_ENABLED=1, -DMBED_DEBUG and -g3 develop.jason and release.jason do not contain the -DMBED_TRAP_ERRORS_ENABLED=1 or -DMBED_DEBUG switch and the -g switch level is -g1 instead of -g3

If the Multi-Tech example is built using either develop.jasson or release.jason the code the getInstance(plan) call returns running the example with MTSLog level set to mts::MTSLog::TRACLE_LEVEL report a internal FATAL level error with the getInstance routine.

Calling mDot::getInstance(plan)
[INFO] Initialize radio...
[INFO] Initialize channels...
[INFO] Initialize datarates…
[INFO] Set radio to Private Mode
[FATAL] Cannot access serial flash. Voltage too low!
[FATAL] Cannot access serial flash. Voltage too low!
[DEBUG] Defaulting protected settings.
[FATAL] Cannot access serial flash. Voltage too low!
[DEBUG] Setting to defaults.
[INFO] Initialize channels...
[INFO] Initialize datarates…

when using debug.jason

One of the switch setting cause the MBED error handling system to be invoked instead of the MULTI-Tech error handler

The MBED error handling system print a short cryptic message and then puts the application in a non terminating idle loop waiting for some to attached a debugger and halt the application

Starting GQC Rain Gauge MDot Application
[INFO] Set Guage Interrupt Pin Low Test Passed
[INFO] Creating mDot Instance
[TRACE] Calling mDot::getInstance(plan)
[INFO] Initialize radio...
Timer 0x20005de8 error -3: Resource not available

Call stack' on pause when running debug build

ticker_read(……
wait_us(…
wait_ms(…
mbed_die()
_exit(….
wrap_exit(….
error(….
EvrRtxTimerError(….
svcRtxTimerStop(….
SVC_Handler();

Please log in to post a reply.