Newbie mDot Blinky not working

[G Mc]

I am a newbie with mDot and I am stuck on getting the blinky program to work on an mDot.

Basically if I compile this program using mBed studio: http://os.mbed.com/users/Timsek/code/mbed-os-example-blinky-mDot/
And run it from Mbed Studio via a MTUDK2-ST-MDOT Developer Kit (which is recognised by Mbed studio and I can see the .bin file being placed into the drive created on my Windows 10 machine). The LED (D3 on the developer kit board) does not blink.

However, if I download this pre-built image (https://os.mbed.com/media/uploads/mfiore/mbed-os-example-blinky_mts_mdot_f411re-udk2.bin) found near the bottom of the mDot platform page (https://os.mbed.com/platforms/MTS-mDot-F411/) The LED (D3 on the developer kit board) blinks just fine.

My setup is:
* Windows 10
* I’ve installed the en.stsw-link s/w and two COM ports seem to be recognised as the developer board.
* MBed Studio is version 0.9.1
* The mbed-os is 5.15.3
* I have an mDot board like this: https://os.mbed.com/platforms/MTS-mDot-F411/
* plugged into this developer board: https://www.multitech.com/models/94558010LF

I’ve tried running the MBed CLI using the Windows installer, but I simply get an “mbed command not found” error when running mbed from the command prompt. I could not see any information about how to set this up beyond just running the installer.

I’m sure I am missing something simple, but I’m starting to run out of hair to pull out of my head.

Any advice/help appreciated.

[G Mc]

Update: I finally managed to get the mbed cli downloaded and working using pip (as opposed to the windows installer).

When I import the program and compile it using the CLI, the blink program blinks the LED (as expected).

So the question remains what is going wrong when I try to use the MBED IDE?
If I import the same program into the IDE and run it from the IDE the program does not blink the LED.

Here are the mbed cli commands that I used:

mbed import https://github.com/ARMmbed/mbed-os-example-blinky
cd mbed-os-example-blinky
mbed compile --target MTS_MDOT_F411RE --toolchain GCC_ARM --flash

FWIW, the output of the mbed compile command looks similar to the output generated within the IDE.

There is however one noticeable difference. The final line of the output from the CLI reads:
Image: .\BUILD\MTS_MDOT_F411RE\GCC_ARM\mbed-os-example-blinky.bin

Whereas the final line from the IDE reads:
Image: BUILD/MTS_MDOT_F411RE/ARMC6\mbed-os-example-blinky.bin

Does this imply a different tool chain? Is this the problem? If so, how do I change this in the IDE?

[Jason Reiss]

This looks like an issue with mbed-os-6.0.0-rc1
When I rolled back to mbed-os-5.15.3 both GCC and ARMC6 work.

[G Mc]

Hi @Jason, If I click the libraries tab in the Studio, there is just one library as follows:


mbed-os 5.15.3
Commit: b6370b4c37f3d4665ed1cdcb1afea85396bba1b3
Imported from: https://github.com/ARMmbed/mbed-os/


I’m guessing that that this is the version you mention.

How do I roll back to GCC in the studio?
I did find this fairly recent post https://forums.mbed.com/t/mbed-studio-gnu-arm-gcc/5429 which says it is impossible to switch back to GCC_ARM.

Again, I am a Newbie when it comes to mBed (although I do have experience with other platforms such as Rasberry PI, Arduino, ESP etc).

[G Mc]

Another update, I think the problem somehow relates to how the Studio transfers the compiled code to the mDot.

Using the information here: https://os.mbed.com/docs/mbed-studio/current/installing/switching-to-gcc.html

I have managed to ensure that mbed studio compiles uses ARM-GCC to compile the program. However, the LED still does not blink when the “blinky” program is compiled via the studio.

If I compile the same code (i.e. the same project directory) using the CLI as described above, the LED does blink.

Eventually, I noted (via a binary diff) that the binary files produced from the studio and CLI are 100%, byte for byte identical.

So, I changed the code in the Studio (I vary the blink rate between 100ms and 1000ms), I compiled the code in Studio (no blinking LED). Next I manually copied the .bin file (produced by the Studio) to the mDot’s drive and miraculously, the LED started blinking. I’ve repeated this step several times with different blink delays and a manual copy of the .bin file to the mDot’s USB drive does install and run the Studio compiled program.

But, I shouldn’t have to manually copy this file – What am I missing????

I’ve noticed the following messages in the Studio (which seem to indicate that it is transferring the binary via the USB drive):

<quote>
Build of mbed-os-example-blinky completed: Program compiled
PyOCD deploy failed, deploying using mass storage device…
mbed-os-example-blinky deployed, board may require restarting
</quote>

FWIW, Restarting the board as suggested in the above output doesn’t get the program running either.

Any ideas as to proceed greatly appreciated.

[dicksonemily290@gmail.com]

Did you solve your issue yet? I even don’t know much about this. Thanks!

[G Mc]

I have not resolved the issue, but I have narrowed it down to a problem when the IDE transfers the compiled file to the MDot. This could be used as a workaround.

I’ve managed to narrow it down this way:
1) Build the project in the IDE – observe the LED’s on the developer board blinking which occurs when a file is copied to the “shared drive” on the mDot.
2) Observe that my Blinky program does not operate.

Continuing on from above to show that the compiler generated binary is just fine, the next steps are:
3) Locate the compiled binary (as produced by the IDE) using windows explorer.
4) Manually copy and paste it to the mDot Shared drive. Again observe the LED’s blinking which occurs when a file is copied to the “shared drive”.
5) Observe that the blinky program *does* operate as expected.

I’ve repeated this same process multiple times by changing the delay value (i.e. the rate of blinking) and observed that at step 5, the LED on the will blink at a rate corresponding to the delay that I specified in the program at step 1.

Unfortunately, I’ve been distracted by a few other projects and have had to put any further investigation on hold.

I hope this helps and thanks for your comment

[Author]

Posts