[Mike Fiore]

Boris,

What version of the mbed and mbed-rtos libraries are you using?

Cheers,

Mike

[Mike Fiore]

Ajay,

If you want the mDot to sleep in between sensor reads, you’d use the mDot::sleep call.

Otherwise, you can use a mbed Timer for intervals less than 30 minutes. If you need longer intervals, you can get the time from the RTC. The mDot library initializes the RTC if it isn’t running, so you can just call time(NULL) in your application to get the current time in seconds. The RTC stays running across soft resets and sleeps.

Cheers,

Mike

[Mike Fiore]

Yogesh/Tom,

1) When the mDot is in deep sleep, the only options to wake it up are an external GPIO interrupt or using the RTC alarm. The MCU core is powered down at this point, so no code is executed until the device is woken up.

2) Since the device is restarting, you don’t need to worry about releasing resources or memory.

Cheers,

Mike

[Mike Fiore]

Xiaotian,

Happy to help! Please let us know if you have any other issues.

Thanks for choosing MultiTech!

Cheers,

Mike

[Mike Fiore]

Xiaotian,

I tested your app on my 868 mDot and it seemed to work fine. Here’s the debug output

TTN OTAA mDot LoRa sensor
Checking Config Resetting Config Set SF
Set TxPower
Set Public mode
Set AUTO_OTA Join mode
Set Ack
Set Network Id
Set Network Key
Saving Config
Device ID {0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x43 }
Network Id/App EUI {0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x00, 0x06, 0x56 }
Network Key/App Key {0x7F, 0xA6, 0xF7, 0x50, 0x9F, 0xE5, 0x92, 0x28, 0xD5, 0xF8, 0x79, 0xC3, 0xAD, 0x39, 0x3E, 0xD9 }
Joining Network
TTN OTAA mDot LoRa sensor
Checking Config Resetting Config Set SF
Set TxPower
Set Public mode
Set AUTO_OTA Join mode
Set Ack
Set Network Id
Set Network Key
Saving Config
Device ID {0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x43 }
Network Id/App EUI {0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x00, 0x06, 0x56 }
Network Key/App Key {0x7F, 0xA6, 0xF7, 0x50, 0x9F, 0xE5, 0x92, 0x28, 0xD5, 0xF8, 0x79, 0xC3, 0xAD, 0x39, 0x3E, 0xD9 }
Joining Network

I suggest resetting your config to factory defaults and trying again. Also make sure your serial application (for viewing debug output) is running at 115200 since your app sets the mDot’s debug port to that speed.

Cheers,

Mike

[Mike Fiore]

Andrew,

We’ve seen the same thing. I’m fairly certain this is an issue in the mbed library.

If you’re interested in digging into the issue some, open a ticket on GitHub

https://github.com/mbedmicro/mbed/issues

It’s helpful to reproduce the issue on generally available hardware (e.g. a Nucleo 411) and provide steps and/or a simple application to demonstrate the issue.

Cheers,

Mike

[Mike Fiore]

Ajay,

FM_CREAT creates the file if it does not exist, but I don’t think it overwrites an existing file.

I think the files default to read-only when you open them, so you have to explicitly state that you want to write when you open it.

Cheers,

Mike

[Mike Fiore]

Hi Xiaotian,

The mDots are configured at the factory for either the 915 band and then that configuration is locked in.

It isn’t possible to change the frequency band with the mDot library.

Cheers,

Mike

[Mike Fiore]

The reason it’s currently an issue is because the mDot library is still being built with an old version of the mbed-rtos library. This normally isn’t an issue but the rtos underwent some significant changes recently which caused this issue.

Once we update the library build to use a compatible version of mbed-rtos, the latest rtos versions should be able to be used.

Cheers,

Mike

[Mike Fiore]

Hi Tom,

If you’re building your application using the mbed online compiler, please roll back your mbed-rtos version to revision 111 or earlier. This should resolve the issue.

Cheers,

Mike

[Mike Fiore]

Hi Aamir,

The Log* functions all print to the debug port. Please take a look at the following page.

https://developer.mbed.org/handbook/SerialPC

Cheers,

Mike

[Mike Fiore]

Ashu,

I took a look at the code you posted and nothing jumped out at me. However, you mentioned that you didn’t include the GPS processing code which is presumably where the issue is. If you post the entire application, I’ll try to take a look at it.

Moving in a slightly different direction, MultiTech also has a mDot product called the MTDOT-BOX which might suit your needs.

http://www.multitech.com/brands/multiconnect-mdot-box

The MTDOT-BOX has onboard sensors, GPS, and an LCD screen in addition to the mDot module. We have an example application that uses all of these sensors and does LoRa communication as well.

Cheers,

Mike

[Mike Fiore]

Ashu,

Can you post your source code?

-Mike

[Mike Fiore]

That’s what I suspected. Can you explain in detail what happens when your application has both libmDot (with mbed-rtos) and SerialGPS included?

[Mike Fiore]

Hi Ashu,

Can you explain in more detail what happens when you have mDot.h and SerialGPS.h in your application?

In your version of the application without the mDot library, is RTOS still included in the application? Aka, does anything include rtos.h?

Cheers,

Mike

[Mike Fiore]

Then you should be able to use the ST-Link utility from ST.

http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link004.html

[Mike Fiore]

The application you will need to use on your PC will depend on what JTAG programmer you are using.

Do you not have a UDK2 or MDK board with your mDot?

[Mike Fiore]

Ashu,

The default log level is 0 (NONE). Issue AT+LOG to the device to see the current log level or change it.

Also, make sure your baud rates are correct. The mDot AT firmware uses 115200 as the default for both the debug and AT command ports. You should also disable any hardware or software flow control in your terminal application.

Also, on the UDK board there are two different micro USB connectors. You want to connect to J6 for debug output.

Cheers,

Mike

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

[Mike Fiore]

Ashu,

Usually the first port that enumerates (lower number) is the debug port and the second port is the AT command port.

Also, make sure your baud rates are correct. The mDot AT firmware uses 115200 as the default for both the debug and AT command ports. You should also disable any hardware or software flow control in your terminal application.

Cheers,

Mike

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

[Mike Fiore]

Quentin,

You should be able to create an InterruptIn object for every available GPIO pin if you wish.

Does that answer your question?

Cheers,

Mike

[Mike Fiore]

The processor on the MTCDP is AT91SAM9G20. I took a look at the datasheet and didn’t see any references to TrustZone. I think that part is too old to support it.

Cheers,

Mike

[Mike Fiore]

Hi,

Which product(s) are you interested in?

Cheers,

Mike

[Mike Fiore]

Michael, I’m glad things are working again.

Andrew, I am currently investigating this issue. I was able to reproduce it using our mDot-lora-connect example program on mbed.

https://developer.mbed.org/teams/MultiTech/code/mDot_LoRa_Connect_Example/

I used revision 14 of libmDot and revision 121 of mbed. I’ve found that any revision of mbed-rtos after 111 causes the lockup while joining.

I’ll let you guys know what else I discover.

Cheers,

Mike

[Mike Fiore]

Michael,

If you’re building your application using the mbed online compiler, try rolling the mbed-rtos library back to an earlier revision. I believe version 111 is known to be stable and functional. The latest versions of mbed-rtos seem to cause the mDot library to not function properly. We are looking into this.

Cheers,
Mike

[Mike Fiore]

Michael,

Andrew is correct. There is a filesystem implementation running on the external flash on the mDot. It sounds like there may be an issue with the external flash on your mDot. If this is the case, your configuration may not be getting read from or written to the filesystem correctly. Please open a support case (if you haven’t already) on our portal.

https://support.multitech.com/support

Cheers,
Mike

[Mike Fiore]

Michael,

I suspect there may be a problem with the external flash on your mDot. Can you see any error messages coming out the debug port when you start up the mDot running AT firmware?

The ATZ command does not reset the configuration but it does soft reset the system. If the filesystem on the external flash was unable to be mounted, it would look like the configuration was reset because the mDot would then revert to default configuration.

Cheers,
Mike

[Mike Fiore]

Michael,

In your application folder in the online compiler, you should see folders for mbed, mbed-rtos, and libmDot. If you click on each of those folders, you should see a version number in the top right window on the screen.

The fact that removing the ticker from the weather code makes everything work makes me suspect that the OneSecondTickerISR function is doing taking too long or doing something naughty. What is that ISR doing?

I’m also not sure what the portion of that line of code is doing. It may not be the issue, I’ve just never seen that syntax before.

Cheers,

Mike

[Mike Fiore]

Michael,

Can you post your entire main.cpp?

Also, are you building your application using the mbed online compiler? If so, can you provide the mbed, mbed-rtos, and mDot library versions you’re using?

Cheers,

Mike

[Mike Fiore]

Michael,

Is your mDot in a UDK2 board? It would look like the board on this page:
http://www.multitech.com/brands/mdot-devkit

If that’s the case, PA_1 connects to the D6 LED. That line is also the RTS signal on the external serial port. The LED may not be blinking because the RTS jumper is on the board. It’s in the bank of jumpers near the power connector. You’ll need to pull the RTS jumper off before you see that LED blinking.

If you’re not using a UDK board, can you give me some more information about your setup?

Cheers,

Mike

[Mike Fiore]

Michael,

I’m surprised that code compiles. You’re not creating the DigitalOut object correctly. It should be

DigitalOut led(PA_1);

Cheers,

-Mike

[Author]

Posts