Win10 - tried every port have AT passthrough output on USBSER (COM_14) at 115.2kbps.
No serial system state report output at 9600 on any port.
All documentation seems to be half-baked, incomplete or not relevant.
Both online ide/compiler and mbed Studio are complete no-go. In regard to build, modify and load.
The simplest possible example project: Blinky.
Very frustrating.
Did you find this document? https://os.mbed.com/docs/mbed-os/v5.12/tutorials/serial-comm.html
If so, what could be done to improve it?
Hi Mike,
Please take a look also here: https://os.mbed.com/docs/mbed-os/v5.12/apis/serial.html
It’s possible that your board has a different default baudrate. Link above shows you how to override a baudrate.
It is also worth mentioning that we are actively working on adding serial monitor functionality in Mbed Studio for connected boards. It is coming soon!
Kind Regards
Arek Zaluski
Joe and @arekzaluski
Took a look at the API. It would be helpful if users can identify which of the USB enumerations is the ‘console’ serial port. A new HW platform user and new Mbed user there is little to isolate where the issue lies:
HW or SW.
I’ve iterated through all enumerated ports at all baudrates and have yet to see the out from
sys_state.report_state();
All I receive is the AT pass through message when the board reboots after running the downloaded blinky bin file.
Enumerated ports:
Received on Port 14 at 115.2kbps:
Dragonfly Nano Passthrough v0.1.4
type ‘+’ or ‘-’ to increase or decrease the baud
type ‘E’ or ‘D’ to Enable or Disable PSM
type ‘h’ to display this message
Powering on radio
Radio powered
checking for AT response…
Upon running Blinky, SystemReport output is never received.
Mike
Hi Mike,
I think that both of the issues you see are because the board you are using is officially supported with quite old version of Mbed OS: 5.6
This version is not supported in Arm Compiler 6 hence why Mbed Studio has problems with building it properly. That being said It should work correctly in Online Compiler as it is using both Arm Compiler 5 and 6 to build programs (depending on Mbed OS version).
I’ll try to get access to this board and I’ll confirm it for you.
I’ve already tried as you might note by a separate post.
Just loaded and ran it again - with #define PRINT_AFTER_N_LOOPS 200 changed from 20 to 200.
Again - this time it built and I dumped the binary to the board and it ran - with original value of 20.
And no SystemReport() ouput either.
…effectively the same thing.
I see no place to select compiler and/or OS versions as appropriate required. Where is this located?
I also see no documentation associated with my dev-board defining which versions of OS and tools are required. …lots of holes left to the imagination or to HUGE amounts of time trial & error.
Greatly Appreciate your help and insight!
I believe I’ve identified the issue:
Blinky can build for the following two platforms:
In the meantime I have forcibly selected MTS_DRAGONFLY_L471QG as the build target and I can see in the project folder structure that the L471QG is indeed being built and binary produced.
IS this a Studio issue or Multitech platform issue? How/where can I effect changes to correct this? (If I can).
The binary when manually loaded onto the target does indeed reflect the code modifications. Yay! 
Unfortunately with this mis-identification I cannot run or debug from Studio.
Any next steps to get this moving correctly?
Thanks,
Mike
Surprise-surprise: Manual reselection of correct Target also resolves serial issue.
Port 14 is receiving SystemReport() outputs as expected.
Mike
Hi Mike,
Thank you for providing more information and apologies for not responding in a timely manner. Mbed Studio is using mbed-ls (mbed-ls · PyPI) to discover connected boards. From logs that you sent, I see that mbed-ls discovers first 4 digits of your DEVICE_ID as 0310. This number according to our database should uniquely identify board as MTS_DRAGONFLY_F411RE. MTS_DRAGONFLY_L471QG should have a DEVICE_ID starting with 0312.
We will perform more tests to confirm that mbed-ls and boards database is correct for those 2 boards. I’ll update this thread as soon as I’ll have more information.
Arek
Any updates?
The solution is to update the platform running the Nano version of the Dragonfly with the appropriate DEVICE_ID.
Download & Install the following:
Then run ‘st-LinkUpgrade.exe -force_prog -board -0312’ to program the interface chip on the UDK2 as MTS_DRAGONFLY_L471QG
