I’ve seen related queries on this topic, do I need to add a resistor to a pin or something?
Fez Cerberus won't self-boot -- requires F5
Brett
#2
what do you mean by F5? Do you mean within Visual Studio? If so, please clearly describe the behaviour you’re seeing. Do you have a simple application (LED blinking) that you can demonstrate this with?
Sorry - I was in a rush. With .NETMF I could deploy the software and then upon rebooting the device, the software would execute. With TinyCLR, I can deploy the software, but if I reboot it it will not run; the device seems to do nothing. If I press F5 from within Visual Studio, the software deploys (if changed), and then it starts executing.
Therefore the only way to execute the deployed software is to be attached to Visual Studio and the debugger…
Here’s the device deployment output, when pressing F5:
Looking for a device on transport ‘USB’.
Found device port ‘USB’ with ID ‘58064152-961d-40b1-9bfc-2c8f9f9f08f0’ for transport ‘Usb’.
Starting device deployment.
Attempting to connect to device ‘USB:Cerb’: iteration 0.
Opening port ‘\?\usb#vid_1b9f&pid_0110#6&1eed20e4&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}’.
Attaching debugger engine.
Debugger engine attached.
Querying device assemblies.
Found assemblies:
- TinyCLRApplication1 v1.0.0.0.
- mscorlib v0.6.0.0.
- GHIElectronics.TinyCLR.Devices v0.6.0.0.
Generating device specific assemblies.
Deploying assemblies:
- TinyCLRApplication1 v1.0.0.0 with size 5,420 bytes at ‘C:\Users\erict\Documents\Visual Studio 2017\Projects\TinyCLRApplication1\TinyCLRApplication1\bin\Debug\pe\TinyCLRApplication1.pe’.
- mscorlib v0.6.0.0 with size 76,772 bytes at ‘C:\Users\erict\Documents\Visual Studio 2017\Projects\TinyCLRApplication1\TinyCLRApplication1\bin\Debug\pe\mscorlib.pe’.
- GHIElectronics.TinyCLR.Devices v0.6.0.0 with size 40,924 bytes at ‘C:\Users\erict\Documents\Visual Studio 2017\Projects\TinyCLRApplication1\TinyCLRApplication1\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.pe’.
Total deployment size is 123,116 bytes.
Incrementally deploying assemblies to the device:
All assemblies on the device are up to date. No deployment was necessary.
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.
Brett
#4
ok, so here’s my ask of you. Please create an LED blinky application in TinyCLR and deploy that - it must simply start the blinking onboard LED with no interaction. Make sure it works as you expect under VS. Then, unplug from the PC and do the same test with the board connected to just a power supply - does it work?
Can you also confirm what bootloader version you’re running, and what device you see in device manager when you connect the Cerberus to the PC without having VS loaded? I can’t see mention of a known issue where the Bootloader on the Cerb doesn’t run TinyCLR itself, which is the closest thing I can see your description as being…
Dat_Tran
#5
There is a pin is called Run Application Pin, it is different on each devices. On Cerb, it is PC3 and make sure that pin is high. This pin is used to stop executing the application.
I’ve done that, and as I explained it works fine under VS, but when run with just connected to power, it doesn’t start. I’ve tried both connected to my laptop for power, as well as on a battery supply The red power LED on the FEZ Cerberus is on, so I know it has power. If it’s possible to attach a file to this forum thread, then it will be the blinky project for your perusal.
The TinyCLR Config program shows the Deivce as Cerb, the Name as Cerb and the Version as 0.6.0.0.
Interesting, when I click the Reboot button in TinyCLR, then the blinky program starts up.
In DeviceManager, there is one Universal Serial Bus device: Cerb.
It shows some interesting messages in the Events tab of the Cerb properties window:
2017-12-31 15:15:20 Device not migrated
in the information window:
Device USB\VID_1B9F&PID_0110\6&1eed20e4&0&3 was not migrated due to partial or ambiguous match.
Last Device Instance Id: USB\VID_10C4&PID_800A\106161
Class Guid: {4D36E978-E325-11CE-BFC1-08002BE10318}
Location Path: PCIROOT(0)#PCI(1D00)#USBROOT(0)#USB(1)#USB(3)
Migration Rank: 0xF000FFFFF0000033
Present: false
Status: 0xC0000719
The next entry in events, with the same timestamp:
2017-12-31 15:15:20 Device Configured (winusb.inf)
Device USB\VID_1B9F&PID_0110\6&1eed20e4&0&3 was configured.
Driver Name: winusb.inf
Class Guid: {88BAE032-5A81-49F0-BC3D-A4FF138216D6}
Driver Date: 06/21/2006
Driver Version: 10.0.16299.15
Driver Provider: Microsoft
Driver Section: WINUSB.NT
Driver Rank: 0xFF2000
Matching Device Id: USB\MS_COMP_WINUSB
Outranked Drivers:
Device Updated: false
Parent Device: USB\VID_8087&PID_0020\5&33b10b42&0&1
and the third entry is
2017-12-31 15:15:20 Device started (WINUSB)
Device USB\VID_1B9F&PID_0110\6&1eed20e4&0&3 was started.
Driver Name: winusb.inf
Class Guid: {88BAE032-5A81-49F0-BC3D-A4FF138216D6}
Service: WINUSB
Lower Filters:
Upper Filters:
Ah - that was the reason. I had a beeper connected to PC3 with the other side of the beeper to ground. A pull up resistor would probably have solved the problem, but I moved the beeper to pin 5 of socket 4 (which is PA5) and that solved it. Funny, the circuit worked with .NETMF, so is using PC3 as a boot blocker a new feature in TinyCLR?
e_t_in_Ottawa
#11
I missed it, answering your ask. Thank you to all – John, Dat, and you – for getting to the bottom of this.