Offline SDK build problems

[Neil MacMullen]

Hopefully you can help with some problems I’m having building applications for the mDot.

I have followed the setup instructions detailed at https://developer.mbed.org/teams/MultiTech/wiki/Using-the-mbed-SDK-for-mDot-development. My environment is a Windows 10 PC and I’ve tried using both DOS and Powershell consoles.
I have successfully run

python workspace_tools/build.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 –rtos

to build the libraries and can see that libmbed.a has been created in build\mbed\TARGET_MTS_MDOT_F411RE\TOOLCHAIN_GCC_ARM

I’ve created a folder called myapp and copied main.cpp from the helloworld example as well as the libmdot source.

C:\PERSONAL\PROJ\MBED\MYAPP
| libmDot-0.0.9-1-ge7286ba-GCC_ARM.a
| main.cpp
| mDot.h
|
\—MTS-Utils
MTSCircularBuffer.h
MTSLog.h
MTSText.h
Utils.h

I then try to compile the application using the suggested command:

C:\personal\proj\mbed> python workspace_tools/make.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 –rtos –source=myapp –build=build
[WARNING] Using default settings. Define your settings in the file “workspace_tools/private_settings.py” or in “./mbed_settings.py”
Building project MYAPP (MTS_MDOT_F411RE, GCC_ARM)
Compile: main.cpp
[ERROR] arm-none-eabi-g++: error: myapp\main.cpp: No such file or directory
arm-none-eabi-g++: fatal error: no input files
compilation terminated.

As you can see, the compiler is failing to find the source code.

I have looked at the documentation around the settings.py file(s) and as far as I can see it only affects gcc-related settings such as stdlib location. Since gcc is clearly running I assume that the default settings are ok.

Running with the verbose flag shows this information:

Building project MYAPP (MTS_MDOT_F411RE, GCC_ARM)
Compile: main.cpp
[DEBUG] Command: arm-none-eabi-g++ -std=gnu++98 -fno-rtti -c -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -fno-builtin -ffunction-sections -fdata-sections -MMD -fno-delete-null-pointer-checks -fomit-frame-pointer -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat -abi=softfp -O2 -DTOOLCHAIN_GCC_ARM -DTOOLCHAIN_GCC -DMBED_BUILD_TIMESTAMP=1447965350.18 -DTARGET_CORTEX_M -D__FPU_PRESENT=1 -DTARGET_MTS_MDOT_F411RE -D__MBED__ =1 -DUSE_PLL_HSE_EXTC=0 -DTARGET_M4 -DTARGET_STM -DHSE_VALUE=26000000 -DVECT_TAB_OFFSET=0x00010000 -DTARGET_STM32F4 -D__CORTEX_M4 -DTARGET_STM32F411RE -DARM_MATH_CM4 -DOS_CLOCK=96000000 -Imyapp -Imyapp\MTS-Utils -Imyapp -Imyapp\MTS-Utils -IC:\personal\proj\mbed\libraries\tests\mbed\env -o build\.\main.o myapp\main.cpp

which imples to me that the compiler is being invoked with the correct relative paths but its working directory may be incorrect. If I call the compiler directly from the command line it is able to correctly locate myapp\main.cpp which should rule out a problem with path separators.

C:\personal\proj\mbed>arm-none-eabi-g++ myapp\main.cpp
myapp\main.cpp:7:18: fatal error: mbed.h: No such file or directory
#include “mbed.h”
^
compilation terminated.

There are other things that are clearly ‘wrong’ about the command that make.py is spawning:
– there is a spurious include path to libraries\tests
– include paths for the standard mbed and other related headers are NOT present

The mbed documenation on make.py implies it is used for creating tests rather than standalone programs so I’m questioning whether the documentation for mDot is actually correct? I notice also that mBed now suggests using the yotta build system but unfortunately I haven’t been able to find any references to a suitable yotta mDot target.

Hopefully this is enough information to help you advise on what’s going wrong but I’ll be happy to provide more if needed,.

Thanks, Neil

• This topic was modified 9 years ago by Neil MacMullen.

[Brandon Bayer]

Neil,

Try using the full path to the source and build directories.

-Brandon

[Neil MacMullen]

Brandon,
Thanks for the tip. This addresses the working directory issue but still doesn’t correctly add the appropriate include paths to the command line. For example, mbed.h lives in C:\personal\proj\mbed\libraries\mbed\api\mbed.h but there is no corresponding -I option being generated. Similarly, the required -o library links are missing. Here’s the output from -v… (apologies for any extraneous line-breaks, they’re just an artefact of cutting and pasting from the console)

C:\personal\proj\mbed>python workspace_tools/make.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 –rtos –source=c:\personal\proj\mbed\myapp –build=c:\personal\proj\
mbed\build -v
[WARNING] Using default settings. Define your settings in the file “workspace_tools/private_settings.py” or in “./mbed_settings.py”
Building project MYAPP (MTS_MDOT_F411RE, GCC_ARM)
Compile: main.cpp
[DEBUG] Command: arm-none-eabi-g++ -std=gnu++98 -fno-rtti -c -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-excepti
ons -fno-builtin -ffunction-sections -fdata-sections -MMD -fno-delete-null-pointer-checks -fomit-frame-pointer -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat
-abi=softfp -O2 -DMBED_BUILD_TIMESTAMP=1448025186.8 -DTOOLCHAIN_GCC_ARM -DTOOLCHAIN_GCC -DTARGET_CORTEX_M -D__FPU_PRESENT=1 -DTARGET_MTS_MDOT_F411RE -D__MBED__=
1 -DUSE_PLL_HSE_EXTC=0 -DTARGET_M4 -DTARGET_STM -DHSE_VALUE=26000000 -DVECT_TAB_OFFSET=0x00010000 -DTARGET_STM32F4 -D__CORTEX_M4 -DTARGET_STM32F411RE -DARM_MATH
_CM4 -DOS_CLOCK=96000000 -Ic:\personal\proj\mbed\myapp -Ic:\personal\proj\mbed\myapp\MTS-Utils -Ic:\personal\proj\mbed\myapp -Ic:\personal\proj\mbed\myapp\MTS-U
tils -IC:\personal\proj\mbed\libraries\tests\mbed\env -o c:\personal\proj\mbed\build\.\main.o c:\personal\proj\mbed\myapp\main.cpp
[DEBUG] Return: 1
[DEBUG] Output: c:\personal\proj\mbed\myapp\main.cpp:7:18: fatal error: mbed.h: No such file or directory
[DEBUG] Output: #include “mbed.h”
[DEBUG] Output: ^

Obviously I can manually create a gcc call that will include the appropriate include paths and libraries but isn’t this what make.py is meant to be doing?

Can you confirm that the documentation as written is known to be correct? At the moment I’m not getting a good feeling that make.py is actually the right script to be using!

Thanks,
Neil

• This reply was modified 9 years ago by Neil MacMullen.

[Brandon Bayer]

Neil,

So we are wondering if this is related to Windows 10. Everything you are doing looks correct and are the same commands we use to build on Windows 7. Do you have a Windows 7 pc to try or could you install it in a virtual machine?

-Brandon

[Neil MacMullen]

Thanks Brandon. Good to hear that it has been seen to work at least! I don’t have a Win 7 environment here but I can see if I can spin up a VM over the weekend to try it. If you get a chance to try it on Win 10, I’d also be interested in the result.

Another factor worth mentioning is that I started off by installing yotta on this machine (following the original mbed guidance). I’d hope that the two environments wouldn’t interfere with each other but perhaps I’ve confused python in some way?

[Neil MacMullen]

I wasn’t able to find a Win 7 image but did install the SDK on a fresh windows server 2012 image. I was careful to follow the instructions exactly as written and did not install yotta first. Unfortunately I am still seeing exactly the same problem.

[Neil MacMullen]

Ok – I think I have got to the bottom of this.

When you build the libraries, the build.py script appears to collect build products including header files into a directory called ‘build’ which is in the root mbed folder

When the make.py script is run it automatically adds ‘build’ and appropriate subdirectories to the dependency list.

For both of the above steps, ‘build’ is effectively a hardcoded path.

Make.py also accepts a ‘–build’ option to allow you to specify the target directory for application build products. It appears to remove the contents of this directory before starting the build.

The net result is that if you point –build to a directory called ‘build’ you end up deleting the pre-built library files and the overall build fails since relevant header files and libs cannot be found.

The workaround is to ensure that you specify a –build option that points to a uniquely named directoy, e.g. ‘mybuild’.

Can I suggest stating this explicitly in the documentation, or ideally, modifying the scripts to store the library products in a less vulnerable directory – I would have thought that stashing it inside the ‘libraries’ directory would make more sense.

Neil

• This reply was modified 9 years ago by Neil MacMullen.

[Brandon Bayer]

Ah, good catch Neil. I’ve add a bit to that wiki page to hopefully clarify this for the next person.

-Brandon

[Mike Fiore]

Neil,
Brandon has updated documentation. The mbed SDK is not ultimately under our control. You can open an issue or make a pull request on the mbed SDK Github page.

https://github.com/mbedmicro/mbed

Cheers,
Mike

[Yusuf Goren]

I’m having some related (I think) problems with offline builds.

I have followed all the steps in the Wiki page, but when I want to build my own project (which is nothing but the LoRa Connect example) I get the following error:

main.cpp:(.text.startup.main+0x18): undefined reference to "mDot::getId[abi:cxx11]()"
main.cpp:(.text.startup.main+0x7e): undefined reference to "mDot::setNetworkName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)"
main.cpp:(.text.startup.main+0x9c): undefined reference to "mDot::setNetworkPassphrase(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)"
main.cpp:(.text.startup.main+0x132): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x20e): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x272): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x29c): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x2c6): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"

I have the production library from the developer site and I’m invoking the build as
sudo python workspace_tools/make.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 --rtos --source=/home/yugoren/OEA/git/multitech/mdot/ --build=/home/yugoren/OEA/git/multitech/mbed/build/loraTest/

Could you tell me why the code is not compiling?

Thanks!

[Mike Fiore]

Yusuf,
It looks like you’re missing the mDot library (libmDot). You need to download the offline version of the mdot library from the downloads page on this site, extract the tarball, and put the library and headers into your source folder.

Cheers,
Mike

[Yusuf Goren]

Mike,

I did downloaded libmDot-0.0.9-1 (270) from the developer page and that’s where main.cpp lives. Just to make sure, my directory tree looks like this

/home/yugoren/OEA/git/multitech/mdot
├── libmDot-0.0.9-1-ge7286ba-GCC_ARM.a
├── main.cpp
├── mDot.h
└── MTS-Utils
    ├── MTSCircularBuffer.h
    ├── MTSLog.h
    ├── MTSText.h
    └── Utils.h

I have also tried renaming the archive to `libmDot.a’ with no avail.

Thanks,
Yusuf

[Mike Fiore]

Yusuf,
You shouldn’t have to rename the archive, but it shouldn’t break anything as long as the file type (.a) stays the same.

I don’t see any reason why your build would fail based on what you’ve shared so far. Can you share the contents of main.cpp?

Cheers,
Mike

[Yusuf Goren]

Mike,

Here’s the `main.cpp’ file. It’s the LoRa Connect Example code here:
https://developer.mbed.org/teams/MultiTech/code/mDot_LoRa_Connect_Example/

#include "mbed.h"
#include "mDot.h"
#include "MTSLog.h"
#include <string>
#include <vector>
#include <algorithm>

// these options must match the settings on your Conduit
// uncomment the following lines and edit their values to match your configuration
static std::string config_network_name = "oeacnetw";
static std::string config_network_pass = "oeacnetw";
static uint8_t config_frequency_sub_band = 7;

int main() {
    int32_t ret;
    mDot* dot;
    std::vector<uint8_t> data;
    std::string data_str = "hello!";
    
    // get a mDot handle
    dot = mDot::getInstance();
    
    // print library version information
    logInfo("version: %s", dot->getId().c_str());

    //*******************************************
    // configuration
    //*******************************************
    // reset to default config so we know what state we're in
    dot->resetConfig();
    
    dot->setLogLevel(mts::MTSLog::INFO_LEVEL);

    // set up the mDot with our network information: frequency sub band, network name, and network password
    // these can all be saved in NVM so they don't need to be set every time - see mDot::saveConfig()
    
    // frequency sub band is only applicable in the 915 (US) frequency band
    // if using a MultiTech Conduit gateway, use the same sub band as your Conduit (1-8) - the mDot will use the 8 channels in that sub band
    // if using a gateway that supports all 64 channels, use sub band 0 - the mDot will use all 64 channels
    logInfo("setting frequency sub band");
    if ((ret = dot->setFrequencySubBand(config_frequency_sub_band)) != mDot::MDOT_OK) {
        logError("failed to set frequency sub band %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
    }
    
    logInfo("setting network name");
    if ((ret = dot->setNetworkName(config_network_name)) != mDot::MDOT_OK) {
        logError("failed to set network name %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
    }
    
    logInfo("setting network password");
    if ((ret = dot->setNetworkPassphrase(config_network_pass)) != mDot::MDOT_OK) {
        logError("failed to set network password %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
    }
    
    // a higher spreading factor allows for longer range but lower throughput
    // in the 915 (US) frequency band, spreading factors 7 - 10 are available
    // in the 868 (EU) frequency band, spreading factors 7 - 12 are available
    logInfo("setting TX spreading factor");
    if ((ret = dot->setTxDataRate(mDot::SF_10)) != mDot::MDOT_OK) {
        logError("failed to set TX datarate %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
    }
    
    // request receive confirmation of packets from the gateway
    logInfo("enabling ACKs");
    if ((ret = dot->setAck(1)) != mDot::MDOT_OK) {
        logError("failed to enable ACKs %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
    }
    
    // save this configuration to the mDot's NVM
    logInfo("saving config");
    if (! dot->saveConfig()) {
        logError("failed to save configuration");
    }
    //*******************************************
    // end of configuration
    //*******************************************

    // attempt to join the network
    logInfo("joining network");
    while ((ret = dot->joinNetwork()) != mDot::MDOT_OK) {
        logError("failed to join network %d:%s", ret, mDot::getReturnCodeString(ret).c_str());
        // in the 868 (EU) frequency band, we need to wait until another channel is available before transmitting again
        osDelay(std::max((uint32_t)1000, (uint32_t)dot->getNextTxMs()));
    }

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

    while (true) {
        // send the data to the gateway
        if ((ret = dot->send(data)) != mDot::MDOT_OK) {
            logError("failed to send", ret, mDot::getReturnCodeString(ret).c_str());
        } else {
            logInfo("successfully sent data to gateway");
        }

        // 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;
}

Thanks,
Yusuf

• This reply was modified 8 years, 10 months ago by Yusuf Goren.

[Mike Fiore]

Ok, if you just copied and pasted that code, that should be fine.

A couple other things:

1) You’re running the build.py script before make.py, right?
2) Why are you using sudo with make.py? I’m wondering if that might be causing issues.
3) What are the file permissions on the library files? Can you do a ls -l in your source directory?

Cheers,
Mike

[Yusuf Goren]

Mike,

1,2) Yes I did the build following the git page for mbed. I bumped into a problem with the private settings first time I was running build.py, that’s why I had used sudo all over the place.

Now I recloned the git library (mbedmicro/mbed), recompiled with build.py, and remake with make.py and I have still the same errors.

ls -lR in the source directory yields

/home/yugoren/OEA/git/multitech/mdot/:
total 376
-rw-rw-r-- 1 yugoren yugoren 338038 Sep  9 12:08 libmDot-0.0.9-1-ge7286ba-GCC_ARM.a
-rw-rw-r-- 1 yugoren yugoren   4380 Jan 22 10:25 main.cpp
-rw-rw-r-- 1 yugoren yugoren  29792 Sep  9 12:07 mDot.h
drwxrwxr-x 2 yugoren yugoren   4096 Jan 22 10:00 MTS-Utils

/home/yugoren/OEA/git/multitech/mdot/MTS-Utils:
total 20
-rw-rw-r-- 1 yugoren yugoren 5997 Sep  9 12:07 MTSCircularBuffer.h
-rw-rw-r-- 1 yugoren yugoren 3465 Sep  9 12:07 MTSLog.h
-rw-rw-r-- 1 yugoren yugoren 3104 Sep  9 12:07 MTSText.h
-rw-rw-r-- 1 yugoren yugoren 1049 Sep  9 12:07 Utils.h

Thanks a lot,
Yusuf

[Mike Fiore]

Can you elaborate on the problem with private settings? I’ve never had to use sudo to run the python scripts, so I’m not sure if that would have any adverse affects or not.

Also, what toolchain are you using?

[Yusuf Goren]

Mike,

First, I have tried to compile the mbed libraries using the arm-none-gcc that comes with Ubuntu, but that didn’t work (that was when I had to sudo the command). Then I downloaded the GCC ARM Embedded compiler that you linked on the Wiki page, but I forgot to remove sudo from the command. But after your comment on how sudo shouldn’t be required, I removed the whole git library, recloned it and recompiled without sudo and it worked.

Let me recap my final setup with the toolchain: I have the GCC ARM Embedded toolchain from
https://launchpad.net/gcc-arm-embedded
that is located in /home/yugoren/bin/arm-none-eabi-2015q4/, the settings file (workspace_tools/private_settings.py) reads

GCC_ARM_PATH = "/home/yugoren/bin/arm-none-eabi-2015q4/bin"

The build using

python workspace_tools/build.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 --rtos

is successful (with Build successes: * GCC_ARM::MTS_MDOT_F411RE) but the make for the project using

python workspace_tools/make.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 --rtos --source=/home/yugoren/OEA/git/multitech/mdot/ --build=/home/yugoren/OEA/git/multitech/mbed/build/loraTest/

fails with the error message

main.cpp:(.text.startup.main+0x28): undefined reference to "mDot::getId[abi:cxx11]()"
main.cpp:(.text.startup.main+0x8c): undefined reference to "mDot::setNetworkName(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)"
main.cpp:(.text.startup.main+0xaa): undefined reference to "mDot::setNetworkPassphrase(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)"
main.cpp:(.text.startup.main+0x12a): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x1c0): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x240): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x26c): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
main.cpp:(.text.startup.main+0x298): undefined reference to "mDot::getReturnCodeString[abi:cxx11](long const&)"
/home/yugoren/OEA/git/multitech/mbed/build/loraTest/./main.o:main.cpp:(.text.startup.main+0x2c4): more undefined references to "mDot::getReturnCodeString[abi:cxx11](long const&)" follow

Thanks a lot,
Yusuf

[Mike Fiore]

Yusuf,
Can you try downloading a fresh copy of the library tarball? Maybe something got corrupted at some point and is causing the build to fail.

Here’s the MD5 from the copy I extracted and successfully built with, along with file sizes and permissions:

md5sum libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz
cab21380f486c9313f60b425a221fe35 libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz

ls -lh libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz
-rw-rw-r– 1 mfiore mfiore 124K Jan 22 12:04 libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz

ls -lh mdot/*
-rw-rw-r– 1 mfiore mfiore 331K Jan 22 12:04 mdot/libmDot-0.0.9-1-ge7286ba-GCC_ARM.a
-rw-rw-r– 1 mfiore mfiore 30K Jan 22 12:04 mdot/mDot.h

mdot/MTS-Utils:
total 20K
-rw-rw-r– 1 mfiore mfiore 5.9K Jan 22 12:04 MTSCircularBuffer.h
-rw-rw-r– 1 mfiore mfiore 3.4K Jan 22 12:04 MTSLog.h
-rw-rw-r– 1 mfiore mfiore 3.1K Jan 22 12:04 MTSText.h
-rw-rw-r– 1 mfiore mfiore 1.1K Jan 22 12:04 Utils.h

Hope this is helpful!

Cheers,
Mike

• This reply was modified 8 years, 10 months ago by Mike Fiore.

[Yusuf Goren]

Mike,

Found the problem! I was using 2015q4 for GCC ARM Embedded and now it compiles perfectly with 2015q3. Sorry about the trouble.

Thanks,
Yusuf

• This reply was modified 8 years, 10 months ago by Yusuf Goren.

[Mike Fiore]

That is the next thing I was going to suggest! Glad you got it figured out!

-Mike

[Author]

Posts