[Mike Fiore]

Michael,

All GPIO pins on the mDot should be interrupt capable.

Cheers,

Mike

[Mike Fiore]

Will,

The prototypes are actually as follows

    /** This method enables bulk writes to the Tx or write buffer. This method
    * blocks until all the bytes are written.
    *
    * @param data the byte array to be written.
    * @param length the length of data to be written from the data parameter.
    * @returns the number of bytes written to the buffer, which should be
    * equal to the length parameter since this method blocks.
    */
    int write(const char* data, int length);

    /** This method enables bulk reads from the Rx or read buffer. This method
    * blocks until the amount of data requested is received.
    *
    * @param data the buffer where data read will be added to.
    * @param length the amount of data in bytes to be read into the buffer.
    * @returns the total number of bytes that were read. This should be equal
    * to the length parameter since this is a blocking call.
    */
    int read(char* data, int length);

I believe the issue is that your buffer is of type unsigned char[], while the write and read functions accept types const signed char[] and signed char[] respectively. Try casting to those types like this

sp.write((const char*)Send_Buffer, bytes);
bytes = sp.read((char*)Send_Buffer, 160);

Cheers,

Mike

[Mike Fiore]

Will,

I didn’t have the setup to actually test the code I posted, so I apologize that it didn’t work. I’m glad you were able to get things working!

Let us know if you have any other issues!

Cheers,

Mike

[Mike Fiore]

Will,

Pins D0/PA_3 and D1/PA_2 are muxed to USART2 according to table 9, Alternate Function Mapping, of the STM32F411RE datasheet.

http://www.st.com/content/ccc/resource/technical/document/datasheet/b3/a5/46/3b/b4/e5/4c/85/DM00115249.pdf/files/DM00115249.pdf/jcr:content/translations/en.DM00115249.pdf

Try adding the following line after your sp.format() line

USART2->CR1 |= USART_CR1_PCE;

Hope this helps!

Cheers,

Mike

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

[Mike Fiore]

Hi,

The easiest way to update firmware on an mDot is using a UDK2 or MDK.

http://www.multitech.com/models/94558010LF
http://www.multitech.com/models/94558020LF

You may also be able to update with a JTAG programmer, but we don’t officially support that scheme. The interface on the UDK2 and MDK uses SWD to communicate with the processor on the mDot. The mDot pinout diagram shows where the JTAG/SWD pins are

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

Cheers,

Mike

[Mike Fiore]

Will,

That makes more sense. Sounds like if you configure for 8 data bits with the parity bit, you actually get 7 data bits + 1 parity bit (total of 8 bits per word). If you need 8 data bits + 1 parity bit, try using 9 instead of 8 for the data bits in your format call. I think that might get you what you want.

Cheers,

Mike

[Mike Fiore]

Will,

A few things…

1) Try bumping your baud rate up to at least 9600. I don’t think rates slower than that are supported.

2) Looks to me like you are configuring the port for no parity, not odd parity.

3) You aren’t checking the return value of the write function. You don’t really know if it’s failing or succeeding. Also, how are you so sure that the write call isn’t blocking? Even at 1200 baud, sending 10 bytes should take less than 100ms.

4) The default size for both the TX and RX buffers is 256 bytes. TxFull won’t return true until there are 256 bytes in the buffer waiting to be sent. At this point, the write function would also return 0 immediately because the TX buffer is full.

I suggest checking return values and bumping up your band rate. You should not need to wait in between sending bytes, and the write functions should not be overwriting unsent data in the TX buffer.

Cheers,

Mike

[Mike Fiore]

Hi Adrian,

Please open a case on our support portal:

https://support.multitech.com/support

Cheers,

Mike

[Mike Fiore]

Will,

No delay is required between raising radio power and radio reset. The radio_pwr line just has to be raised first.

Cheers,

-Mike

[Mike Fiore]

Hi Michael,

The analog reference voltage on the mDot is VDD3, which is 3V. Once pins are configured as analog input, they are no longer 5V tolerant, meaning that >3V should never be applied to a pin in analog input mode. This is why you’re getting strange and inconsistent results.

You’ll need to scale down the voltage from your sensor before trying to read it with an analog input pin on the mDot.

Cheers,

Mike

[Mike Fiore]

Will,

The Dragonfly low power example program you mentioned

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

demonstrates how to properly shut down and turn on the radio.

You should raise the radio_pwr line before raising the radio_reset line. Raising these lines in the opposite order as your application is currently doing could be the cause of your delays, I think.

That is what I noticed right away, but since I don’t have your entire application, I can’t know for sure if there are any other issues.

Cheers,

Mike

[Mike Fiore]

Adrian,

Schematics for the EVB can be found on the developer page:

http://www.multitech.net/developer/products/multiconnect-mdot-box-and-evb/evb-schematics/

Cheers,

Mike

[Mike Fiore]

Felix,

For issuing AT commands to the mDot, this board will probably suffice. You will not, however, be able to flash new programs on your mDot or see debug output when using this board.

Our MDK (Micro Developer Kit) board, on the other hand, allows you to flash your mDot with new programs, see debug output as well as use the AT command port, and has been fully tested with the mDot. Here’s a link:

http://www.multitech.com/brands/micro-mdot-devkit

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Adrian,

Based on the website, it sounds like they use GCC by default:

http://timor.atollic.com/truestudio/building/

That being said, we don’t support Atollic for the MTDOT-EVB. You might be able to get it to work, but we don’t have any guides or instructions.

A compromise might be to use Atollic to browse and edit your source code and then use the mbed SDK tools to build your application. We have a wiki page on mbed that explains how to use the mbed SDK tools:

https://developer.mbed.org/teams/MultiTech/wiki/Using-the-mbed-SDK-for-mDot-development

Cheers,

Mike

[Mike Fiore]

You said you exported for GCC, but you never said what toolchain Attolic is using to compile. Is Attolic using GCC or something else?

[Mike Fiore]

We don’t have any templates, unfortunately.

Have you added the mDot library itself to your project in addition to the headers and other source files?

[Mike Fiore]

Michael,

Two things:

1) I don’t think 4800 baud is supported. I suggest using 9600 or faster.

2) Is SerialGPS a class you’ve defined? If you use a standard Serial object instead, does that work?

Cheers,

Mike

[Mike Fiore]

Michael,

Pins PA_9 & PA_10 are the USB debug interface. The other available UART is on pins PA_2/SERIAL_TX & PA_3/SERIAL_RX. Are you using PA_2 & PA_3? If not, please try those, e.g.

Serial gps(SERIAL_TX, SERIAL_RX);

The default baud rate of mbed Serial objects is 9600. You can change it with the Serial::baud() function.

Cheers,

Mike

[Mike Fiore]

Adrian,

Try 7-Zip:

http://www.7-zip.org/

Cheers,

Mike

[Mike Fiore]

Michael,

The mDot has a “hard” serial port available in addition to the USB debug port. Here’s a link to the pinout:

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

You should be able to create a mbed Serial object with those two pins to communicate with your GPS module.

Hope this helps!

Cheers,

Mike

[Mike Fiore]

Hi Adrian,

What toolchain are you using? I’d guess GCC with Attolic.

If that’s the case, the reason your build is probably failing because the mbed exporter gave you the ARMCC build of the mDot library. Try replacing it with the GCC build, which can be found here

Downloads

Version 1.0.8-1 of the mDot library is currently the latest release.

Hope this helps!

Cheers,

Mike

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

[Mike Fiore]

There are some configuration files the mDot maintains on the filesystem. One of them contains the frequency band the device operates in and the device ID. When you erased the entire flash, your mDot lost its configuration and reverted to defaults (915 frequency band).

Were you storing any files in the filesystem? It may have been full, which would cause an upgrade/transfer via the bootlaoder to fail.

Even though upgrading via the bootloader fails, can you still flash via the normal drag-and-drop method?

-Mike

[Mike Fiore]

I’m not aware of any unofficial progress towards that goal. However, in addition to posting on our forum, you could create a topic on the mbed site and/or search around the mbed site to see if anybody else has attempted something similar.

-Mike

[Mike Fiore]

Terrence,

We don’t have any official support for netmf. The C++ mbed environment is all that’s officially supported at this time.

I’m not sure what the certification status of the product would be if you went down that road. The mDot was certified by FCC, LoRaWan, etc using the mDot software developed in mbed.

Cheers,

Mike

[Mike Fiore]

I see. Didn’t realize you weren’t using a UDK. The serial debug port also comes out the 40 pin connector, so if you have a TTL to USB cable or something similar, you could wire that up to get your debug output.

-Mike

[Mike Fiore]

Will,

Is there a reason you can’t use the USB debug port that’s already provided for your additional configuration requirements? That port provides stdio for your Dragonfly.

Cheers,

Mike

[Mike Fiore]

Will,

You are correct that the USB port on the Dragonfly itself can be connected to either the radio or the processor. And yes, pin A10 controls the USB switch as the documentation states.

However, please note that the USB port on the Dragonfly itself if not the port debug messages come from. Like I said in my last post, you need to connect the J6 USB connector on the UDK board to your PC in order to get debug messages from the processor. A COM port should enumerate, and that is where the debug messages will be (printf calls from your program, etc).

You may have to do some work to use the USB on the Dragonfly’s processor. I don’t think mbed has full USB support for the STM32F411.

Cheers,

Mike

[Mike Fiore]

Will,

The USB port on the Dragonfly itself bypasses the processor and gives you a direct connection to the radio. The debug messages come out of the USB port from the UDK2 board (connector J6) – the same port you connect to flash a new program on the Dragonfly.

When you connect that USB port, you should see a new COM port appear. This is the USB debug port – where you will see debug messages from the Dragonfly.

Make sure you configure your terminal program to match the baud rate of the Dragonfly. It is 9600 by default but your application can change it if you wish.

Cheers,

Mike

[Mike Fiore]

A user wouldn’t know that information is leftovers unless they asked, I suppose.

Logging output should generally be easily readable. If you have any other questions about specific output, feel free to ask!

-Mike

[Mike Fiore]

Michael,

You’re looking for

std::vector getDeviceId();

See mDot.h in the mDot library for more details.

Cheers,

Mike

[Author]

Posts