Important changes to forums

We’re making some changes to the Mbed forums. From 10th December 2019 all new discussions will take place on our new forum site. You can continue to reply to existing threads for the next two weeks. After that we will archive this forum so you can return to useful posts in the future.

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();

You need to log in to post a reply