[Mike Fiore]

Michael,

I’m not sure I understand what you mean.

We don’t have any documentation that explains all of the logging coming out of the mDot library. We have tried, however, to make said logging understandable.

Can you clarify what you’re asking for?

Cheers,

Mike

[Mike Fiore]

Michael,

I’m assuming you’re talking about the 00000037 part of that line. It’s just leftover debug logging – the value getting printed is the RTC->ISR register.

Cheers,

Mike

[Mike Fiore]

Not all the LEDs on the board will light up just from applying power, but you should see at least the PWR LED light up.

Do you have an mDot on the UDK2? Does it enumerate as a mass storage device named MULTITECH when you connect the USB cable to your PC?

[Mike Fiore]

I believe if you add yourself to the “dialout” group, you won’t have to use sudo when starting minicom.

Cheers,

Mike

[Mike Fiore]

Hi Kurt,

Do you see anything interesting in the mDot debug logs or the network server logs on your Conduit? Can you post them?

If you’ve got an AEP conduit, the network server is logging to /var/log/messages. The mDot debug logs come out of the virtual com port provided by the USB connection.

Cheers,

Mike

[Mike Fiore]

Gavin,

PeripheralPins.c in the mDOt platform support lists all the pins that are PWM capable.

https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_STM/TARGET_STM32F4/TARGET_MTS_MDOT_F411RE/PeripheralPins.c

I did some reading on this and it sounds like pins that are run by the same timer must have the same frequency, but each can have a different duty cycle (just FYI since you said you were OK with this).

PA_12 is not listed as a PWM capable pin, so you’ll need to find a replacement for that one.

Hope this helps!

-Mike

[Mike Fiore]

Hi Chuck,

It sounds like you have a SocketModem iCell.

http://www.multitech.com/brands/socketmodem-icell

Is that correct?

How are you interfacing to that device? Are you sure the PPP link is up before you try to ping?

Cheers,

Mike

[Mike Fiore]

Hi,

We’ve used the SparkFun XBEE Shield before and they work just fine with the mDot.

https://www.sparkfun.com/products/12847

Cheers,

Mike

[Mike Fiore]

Hi Xiong,

Please take a look at our documentation here:

Conduit mPower: LoRa Communication and Node-RED

It demonstrates how to send data from the Conduit to the mDot.

Cheers,

Mike

[Mike Fiore]

Terrence,

The mDot library has a function called getDeviceId() that returns the mDot’s unique ID. If you are using the AT firmware, you’d want to use AT+DI.

Cheers,

Mike

[Mike Fiore]

Yusuf,

1-3 are correct. For 4, all those pins can be use as digital ins and outs. Only the pins with a UDK2 pin name staring with A can be used as analog pins.

Cheers,

Mike

[Mike Fiore]

Shaun, excellent! I’m glad that worked out for you.

Happy debugging!

-Mike

[Mike Fiore]

Dejan,

Did you erase the entire flash part on your mDot at any point? The mDot configuration is saved to the flash, so this would have erased it and given you the default device ID of all 0s.

Can you post some trace level debug info from around when mDot::getInstance() is getting called? That will give us information about whether or not the flash is functioning properly.

Thanks,

Mike

[Mike Fiore]

Dejan,

Glad you had success!

Since my last post on this thread, I have verified that OpenOCD is a viable option for debugging as well. Here are the steps…

mbed devices can be debugged using OpenOCD

A pretty good tutorial can be found [http://mcuoneclipse.com/2015/03/22/openocdcmsis-dap-debugging-with-eclipse-and-without-an-ide/ here]

* download OpenOCD from https://sourceforge.net/projects/openocd/files/openocd/0.9.0/
* extract tarball
    tar -xzvf openocd-0.9.0.tar.gz
* make and install OpenOCD
    configure; make; sudo make install
* add self to plugdev group (linux)
    sudo usermod -a -G plugdev <username>
* copy udev rules for debug interfaces (linux)
    cp /usr/local/share/openocd/contrib/99-openocd.rules to /etc/udev/rules.d/
* connect UDK2/MDK/etc
* start openocd
    openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/local/share/openocd/scripts/board/st_nucleo_f4.cfg
* start gdb in another terminal
    arm-none-eabi-gdb
* connect your gdb instance to the gdbserver OpenOCD is running
    (gdb) target remote localhost:3333
* load the symbol file into gdb - this is the .elf file in the same directory your binary was in
    (gdb) symbol-file <path to .elf>
* halt and reset the target
    (gdb) monitor reset init
* now you're ready to debug!

Make sure your application (and the mbed libraries) were built with debug symbols! The simplest way is to use the "-o debug-info" with the build and make scripts.

Cheers,

Mike

[Mike Fiore]

Shaun,
I realized the info I gave you was incomplete. Here’s an updated series of steps to debug your mDot:

* download OpenOCD from https://sourceforge.net/projects/openocd/files/openocd/0.9.0/
* extract tarball
tar -xzvf openocd-0.9.0.tar.gz
* make and install OpenOCD
configure; make; sudo make install
* add self to plugdev group (linux)
sudo usermod -a -G plugdev
* copy udev rules for debug interfaces (linux)
cp /usr/local/share/openocd/contrib/99-openocd.rules to /etc/udev/rules.d/
* connect UDK2/MDK/etc
* start openocd
openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/local/share/openocd/scripts/board/st_nucleo_f4.cfg
* start gdb in another terminal
arm-none-eabi-gdb
* connect your gdb instance to the gdbserver OpenOCD is running
(gdb) target remote localhost:3333
* load the symbol file into gdb – this is the .elf file in the same directory your binary was in
(gdb) symbol-file * halt and reset the target
(gdb) monitor reset init
* now you’re ready to debug!

Make sure your application (and the mbed libraries) were built with debug symbols! The simplest way is to use the “-o debug-info” with the build and make scripts.

Also, here’s a good tutorial I found:

OpenOCD/CMSIS-DAP Debugging with Eclipse and without an IDE

Cheers,

Mike

[Mike Fiore]

Roman,

AT+TXN always returns 0 in the 915 frequency band.

-Mike

[Mike Fiore]

Roman,

Unfortunately, no. The next channel is randomly chosen out of the available channels in order to minimize collisions with other LoRa endpoints. If you enable trace logging, you can probably see what channel is being used, but there isn’t a programatic way to find out.

Can I ask why your application needs to know which channel is being used?

-Mike

[Mike Fiore]

Roman,

Yes, the frequency hopping is done for you.

-Mike

[Mike Fiore]

Lawrence,

You are correct. The mDot supports 868.1MHz, 868.3MHz, and 868.5MHz by default.

The other 5 channels are network configured. The device receives this information in the join accept message in OTA join modes. These 5 channels are based on a configured center frequency and spaced 200kHz apart.

The MTS network server defaults this parameter to 869.5MHZ, which yields 869.1MHz, 869.3MHz, 869.5MHz, 869.7MHz, and 869.9MHz as the 5 network channels.

There are 4 different duty cycle bands specified for the 868MHz frequency band. This default configuration spans all 4 bands, which is why it takes a few transmissions in rapid succession before you see the “no free channel” error.

When a channel in a specific duty cycle band is used, all the channels in that band must stay off the air until the time off air requirements for that band have been met. After that, all channels in that band are available for use.

Hope this helps!

-Mike

[Mike Fiore]

Manuel,

I’m not very familiar with Arduino. By default the mDot runs an AT command interface on the serial port at 115200 baud. You should be able to send “AT” and get an “OK” back.

We have a developer page for the mDot on mbed, which goes over the pinout and many of its features:

https://developer.mbed.org/platforms/MTS-mDot-F411/

We also have documentation for the AT commands (see chapter 15):

http://www.multitech.com/manuals/s000612_1_6.pdf

Hope this helps!

-Mike

[Mike Fiore]

Shaun,

It doesn’t look like pyOCD has support for very many ST targets yet.

https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/board/mbed_board.py

The mDot has a STM32F411 processor, which isn’t in that list. You could try adding it if you wanted.

However, OpenOCD does have support for ST targets. I was able to start a gdb session to debug my mDot by following these steps:

* download OpenOCD from https://sourceforge.net/projects/openocd/files/openocd/0.9.0/
* extract tarball
* run configure; make; sudo make install
* add self to plugdev group (linux)
* copy /usr/local/share/openocd/contrib/99-openocd.rules to /etc/udev/rules.d/ (linux)
* connect USB from UDK2
* run openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/local/share/openocd/scripts/board/st_nucleo_f4.cfg
* in another terminal, run arm-none-eabi-gdb
* in the gdb prompt, type target remote localhost:3333

Documentation for OpenOCD 0.9.0 is here:

http://openocd.org/doc-release/pdf/openocd.pdf

Make sure your application (and the mbed libraries) were built with debug symbols!

Hope this helps!

-Mike

[Mike Fiore]

Guillermo,

Your mDots should have a model number silkscreened on the PCB. It should end in “LA” or “LB”. If it ends in “LA”, that mDot is from before the HW spin and won’t be able to achieve the uA range consumption in deepsleep. If it ends in “LB”, that mDot is from after the HW spin and should be able to achieve the low current draw.

I don’t think it’s a change you can make yourself as we switched to a different regulator.

If you have dots with a model number ending in “LA”, you will need to get newer ones to get the lowest current in deepsleep.

Cheers,
Mike

[Mike Fiore]

Lawrence,
Does the screen on the dotbox display values in that same range?

Cheers,
Mike

[Mike Fiore]

Here’s a link to the mDot platform page on mbed: https://developer.mbed.org/platforms/MTS-mDot-F411/

Any pin that has a UDK2 pin name of A# should be usable as an analog input.

[Mike Fiore]

Also, note that pin 1 on the mDot is VIN which is not VCC and will not power your sensor. If you want to power your sensor from the mDot, you need to connect pin 24 VOUT to your sensor’s VCC.

[Mike Fiore]

Pin A0 is an analog pin, so that seems reasonable.

Does the documentation for the sensor suggest using a resistor or any other component?

[Mike Fiore]

Neil,

The mdot page on mbed has some documentation: https://developer.mbed.org/platforms/MTS-mDot-F411/

Associate and On/sleep pins are used by the factory AT firmware and are free for use by your application. Keep in mind that if you want to put the device in deepsleep mode and wake up with an interrupt, pin D3/XBEE_CTS/XBEE_DIO7/PA_0 is the only pin that can be used.

Cheers,
Mike

[Mike Fiore]

You don’t need to configure anything to use the analog input – just create an AnalogIn object and call read().

[Mike Fiore]

Hi Dejan,

The mbed debug page (https://developer.mbed.org/handbook/Debugging) suggests using Keil MDK for debugging. However, we don’t currently support exporting to that IDE for the mDot.

I suggest using pyOCD. Here’s a page describing how it works and how you can use it: https://developer.mbed.org/blog/entry/Debugging-from-GDB-using-pyOCD/

Cheers,
Mike

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

[Mike Fiore]

Howard,

I’m not sure exactly what version of Keil tools are being used in the online compiler. You might be able to find out by posting a question on mbed. I heard ARMCC v5.06 in a different conversation with somebody at ARM, but I can’t guarantee that’s correct. It would be better to ask them directly.

I wouldn’t expect your binary built with a different toolchain to be exactly the same size as the binary you get from the online compiler. Your version probably doesn’t have our bootloader prepended to it, while the version from the online compiler does.

There is a “verbose” checkbox towards the bottom right of the online compiler page when you have a program selected. If you check that before you compile an choose “compile all” you should see all the debug output from the compiler and linker. You should be able to see what options, etc are being used from that output.

Cheers,
Mike

[Author]

Posts