I did some testing with NetMF on some FEZ boards years ago. I teach robotics one day a week at a private school now, in my retirement, and after the school year ended last week, did some retrospection. Our curriculum last year tried to jump students from Scratch to C++ on Arduino, which proved too great a stretch for many of them. So I have been playing around with some alternatives, like MicroPython on the Seeed Studio Xiao RP2040 and RP2350 boards.
Some of the students have been through a C# on Unity course, so I got to thinking about how the complexity of “top-level” C# would compare to MicroPython. Then I wondered whatever happened to .Net Micro Framework. I looked at .Net nanoFramework. I’ve gotten the TinyCLR emails from GHI down through the years so I also looked at that. The FEZ Flea and Pico boards are interesting (an Arduino Nano compatible board would be even better), especially since the motor driver boards that I designed for the class have a Xiao socket. (Unfortunately, I don’t think the Flea will be drop-in compatible, because the Flea has fewer pins configurable as PWM outputs, and I didn’t route the board with that in mind.)
After a few growing pains, I have test programs running on both the FEZ Flea and Pico boards. I have noticed an oddity, possibly a problem: After Build…Deploy, I have to reset (Pico) or power cycle (Flea) to get the program running. If I click on Run instead of Build…Deploy, after every code change I have to click on Run twice to get the program running. This seems broken to me.
When you F5 run, the system should latch on the debugger and start running your program. If you ctl+F5 then the system should load your program and run.
There is no need for reset. What software are you using? What do you see in the output window?
I agree that is how it should work. But that is not what I observe. With this test program:
using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Pins;
using System.Threading;
namespace TinyCLRApplication1
{
class Program
{
static void Main()
{
var led = GpioController.GetDefault().OpenPin(SC13048.GpioPin.PA8);
led.SetDriveMode(GpioPinDriveMode.Output);
while (true)
{
led.Write(GpioPinValue.High);
Thread.Sleep(500);
led.Write(GpioPinValue.Low);
Thread.Sleep(500);
}
}
}
}
and with a FEZ Pico connected, I get the following output after changing the delays and pressing CTRL-F5:
Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'e3a40269-523b-4cde-9f69-79c1e2c963ed' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:SC13048': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#8&35eed263&0&4#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
- test_led v1.0.0.0 with size 1,208 bytes at 'C:\Users\pmunts\src\ARM\tinyclr\programs\test_led\bin\Debug\pe\test_led.pe'.
- mscorlib v2.4.0.1000 with size 72,556 bytes at 'C:\Users\pmunts\src\ARM\tinyclr\programs\test_led\bin\Debug\pe\mscorlib.pe'.
- GHIElectronics.TinyCLR.Devices.Gpio v2.4.0.1000 with size 4,880 bytes at 'C:\Users\pmunts\src\ARM\tinyclr\programs\test_led\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
- GHIElectronics.TinyCLR.Native v2.4.0.1000 with size 6,200 bytes at 'C:\Users\pmunts\src\ARM\tinyclr\programs\test_led\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 84,844 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
- Address: 0x08047000 => mscorlib
- Address: 0x08058B6C => GHIElectronics.TinyCLR.Native
- Address: 0x0805A3A4 => GHIElectronics.TinyCLR.Devices.Gpio
- Address: 0x0805B6B4 => test_led
Deploying assemblies:
- Writing sector 1: Ignored (same crc)
- Writing sector 2: Ignored (same crc)
- Writing sector 3: Ignored (same crc)
- Writing sector 4: Ignored (same crc)
- Writing sector 5: Ignored (same crc)
- Writing sector 6: Ignored (same crc)
- Writing sector 7: Ignored (same crc)
- Writing sector 8: Ignored (same crc)
- Writing sector 9: Ignored (same crc)
...
- Writing sector 109: Ignored (same crc)
- Writing sector 110: Ignored (same crc)
Assemblies deployed. There are 139,412 bytes left in the deployment area.
And nothing happens, until I push the reset button; then the LED starts flashing.
Addendum: While I was writing this up, I noticed the LED started flashing spontaneously. After some more tests, I ran another CTRL-F5 test with a stopwatch and observed the LED flicker very briefly at about 30 seconds after Assemblies deployed. and start flashing at about 60 seconds. I conjecture that some timeouts are expiring within Visual Studio that release the USB serial port and allow my test program to start. Starting after one minute does not happen after Build…Deploy. I never saw the flicker at 30 seconds again with either Build…Deploy or CTRL-F5. It was only out of the corner of my eye the first time.
You might consider transitioning from Scratch to MicroBlocks. MicroBlocks is a blocks programming system for microcontrollers such as the micro:bit and the super affordable GHI DUELink Cinco:bit (14 boards for $99). What is great about MicroBlocks is not only that it uses blocks; it is also a live, tinkerable environment, just like Scratch. Students can try things out as they work. They learn by doing and are more likely to remain engaged. (That’s very much by design; I was the lead programmer of Scratch for it’s first 11 years and I’m now the lead programmer for MicroBlocks.)
MicroBlocks allows students to explore microcontrollers and electronics without having to learn C++ syntax at the same time. If you are working with high school students who feel ready to try a text language, that’s fine; you could move on to MicroPython (which is also supported by DUELink boards) after spending a few sessions with MicroBlocks.
MicroBlocks is a free, open-source non-profit project, and can run MicroBlocks in a Chrome or EdgeBrowser without installing anything. Learn more at https://microblocks.fun.
I switched everything to TinyCLR 3.0. A quick test indicates no improvement or indeed any change of behavior at all WRT my problem: Build…Deploy still doesn’t reset the target computer, and CTRL-F5 still doesn’t start running until about 62 seconds after Assemblies deployed. I did notice significantly higher flash memory usage: Free flash dropped from 139,412 bytes to 93,952 bytes after deploying the exact same LED test program.
I found this TinyCLR Config known issue fascinating: CLI: reboot need to called twice to reset the device. That sounds a lot like having to CTRL-F5 twice…
I have two Fleas, a Pico, and a Stick. All behave exactly the same, with my program not starting at all after Build…Deploy and starting about 60 seconds after CTRL+F5.
I only have a single Windows machine left; I will try to resuscitate another and try again.
I scrounged up another PC with an old minimal Windows 11 install on it. After installing Visual Studio 2026 and TinyCLR 3, I still get the same misbehavior, with my program not starting at all after Build…Deploy and starting about 60 seconds after CTRL+F5.
We were able to reproduce the issue. It’s a bit annoying, but not a major problem. We’ve already fixed it and will release an updated version soon after we review a few other issues.
To be sure, if you only hit F5, will Visual Studio deploy and run your blink LED program, right? But Ctl+F5 will load the application but will not run till you hit reset, correct?
If the project changes, or a different project is deployed and requires flash sector updates, the board does not start immediately. The user must either wait approximately 60 seconds or press Reset to boot and run the application.