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!
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
All I receive is the AT pass through message when the board reboots after running the downloaded blinky bin file.
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.
I believe I’ve identified the issue:
Blinky can build for the following two platforms:
Currently the Target I have is the second (L471QG) the Dragonfly Nano. Mbed Studio is detecting the Dragonfly Nano as the std Dragonfly (F411RE). I’m not sure who is responsible for reporting this data to Studio. I have made MultiTech aware of this.
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?
Thank you for providing more information and apologies for not responding in a timely manner. Mbed Studio is using mbed-ls (https://pypi.org/project/mbed-ls/) 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.