Is this a new project? Console project ?
@ Gus - Yes. For testing I’m just creating an empty project with no dependencies. On the same machine, the deployment is Ok for the Panda ii’ but it still doesn’t work for the Cerbuino.
How are you powering your board?
Tried a different USB cable?
Tried a different USB port?
Now, the one thing that I would try is to connect the Cerbuino and then from device manager, uninstall the driver, and select the REMOVE the driver option. Then, connect Cerb again and have it recognised by the device and point it to the latest driver
@ Brett - Hi Guys,
The good news.
I have updated the USB driver to GHI_NETMF_WinUsb and tried to plug the cable on all the USB ports. It finally works on 2 of them. I guess it’s the 2.0 USB ports.
I have them updated the bootloader to 4.2.5.0 and the firmware to the same with FEZ_Config. And it works without hanging at the end.
The bad news
After the update, the Cerbuino is getting very, very hot after a few seconds when I plug the USB cable. It’s also no more recognized by Windows. The LEDs on the board are also blinking quickly. Do you have an idea where it can come from?
Thanks again for the support
@ Gus, @ Brett - Hi,
As I mentioned earlier, my Cerbuino is getting very hot after a few seconds (IC1 chip mainly) and then it reboots. I have tried with my old Windows XP PC. It has been recognized in bootloader mode for a couple of seconds, so I was able to re-install the loader. In NETMF mode, sometimes it appears as Unknown Device, then it reboots.
Do you think the card is completely dead? Is there a way to come back to some kind of factory setup?
Regards,
I think you’ve probably fried it. Any time the device doesn’t reliably start is likely a problem.
What code do you have deployed to the device? Can you erase your application and just put a default “blink onboard LED” app on and see if it will continue running for a long period of time, or if it crashes as well?
@ Brett - Hi Brett,
That’s my fear. That will be the first card I’ve fried in that case (and probably not the last one).
It’s still responding for some seconds, but it’s very unstable.
There is no application installed on it. It happens just after the bootloader and firmware upgrade. I have re-installed the bootloader only, but it’s still the same.
With the power supply only, it’s getting hot, but not too much. As soon as the USB cable is connected, the power led becomes very red and the IC1 becomes very hot.
Regards,
What experience level in electronics do you have, and what tools do you have access to ? What power source are you using? The idea that it gets “worse” when you connect USB might highlight something that is power related and might not be the processor…
@ Brett - Hi Brett,
I don’t have much electronic skills. I’m more a software developer. I still have a voltmeter if required and I can have access to some more equipments in our laboratory.
For the power, I’m using an 5V adapter 2A.
Is it possible to use the USB port to transfer data only and not using for the power?
Regards
Voltmeter might show it - but step back for a second. We didn’t really ask you what you were doing when you fried the device in the first place - what were you doing? 
Do you have sensors or other things wired up? Any chance you could have crossed wires or something??
So back to voltmeter. If you can carefully measure the voltages from when you just have the USB connected, and see what the 5v and 3v3 rails show, might help. Do the same when you have just the power pack connected. Do the same when they’re both connected. Make sure you look at whether this changes over time, particularly when you get your unexpected reset.
If you have access to a lab, then I’d be looking for smaller changes that you might only see on a storage oscilloscope, but it might also be worth checking the current draw under different conditions as well as voltages.
It’s not really easy to just use data over USB but not use the power - you would have to cut a USB cable, and re-splice the data wires (D+ and D-) and the ground wire (and shielding if your cable has it) but not the power/V+ wire. You will need to be careful though since the data wire is meant to be precisely the same lengths to enhance data transfer.
@ Brett - Hi Brett,
There was nothing connected to the Cerbuino Bee when it started going wrong. I just had upgraded the tinyboot loader from version 4.2.4.0 to version 4.2.5.0 and after that, the card was not recognized any more and started getting very hot. After some further investigations, I think I have found something that can explain that behaviour. I have compared TinyBooter_4_2_3_1.dfu and TinyBooter_4_2_5_0.dfu that comes with “GHI NETMF v4.2 and .NET Gadgeteer Package (04-30-2013)”. The one that comes with this last delivery is completely corrupted (see the attached images. This probably explains why I can still update the DFU, but the card cannot boot properly after the upgrade. I have tried to install the tinybooter_4_2_3_1 on the board, but the card is still not recognized. It sounds like the wrong tinybooter is not completely erased.
@ ftoure
The corrupted file that you are showing, is that from your PC in the main GHI SDK directory? If so, can you completely uninstall your GHI SDK and reinstall it. But, before reinstalling the SDK, make sure there is nothing left in the GHI directory. Erase any files or folders that were left behind prior to reinstallation.
@ Aron - Hi Aron,
Yes, it’s the file located in “C:\Program Files (x86)\GHI Electronics\GHI OSHW NETMF v4.2 SDK\FEZ Cerb Family\Firmware”. I had uninstalled the SDK and re-installed it to be sure it was the one coming from the installation. I can send you a copy of the file. Finally, I came up to install the 4.2.4.0 version which is correct. I have uploaded the 4.2.4.0.dfu file, but when I check the state and the status with STDFU Tester, it shows STATE_DFU_ERROR. Is there a way to dump the memory in order to check that the dfu file is properly loaded? Normally, we should be able to see something like Cerb_Family or FEZ Cerberus in clear.
this is a long shot… but a very, very easy mistake to make… from our documentation http://www.ghielectronics.com/docs/55/firmware-update-fez-cerberus
[quote]Warning
If you accidentally hit the Upload button instead of Download then the DFU file will become corrupted and you need to get the original DFU file again from the website.[/quote]
@ Jeff - Hi Jeff,
I have sent the file 4.2.5.0 file I have used to GHI. I have got a response from Aron L. Phillips saying that the file I sent (the corrupted one) was the same one than the one he had on his PC. The last update date for this file is also the 04/30/2013, so there is no chance I have modified it. To avoid any doubt, I have uninstalled the GHI OSHW software and re-installed it again and the file was still the same corrupted one. Please check again the file coming from installation of GHI OSHW NETMF v4.2 SDK.msi (04/30/2013) for the Cerberus Firmware at least.
Regards,
Famory
Hello,
I have a similar problem. My development machine (VS 2010/Vista) died recently so I moved my Gadgeteer development tools to a Windows 7 pro (64 bit), running as a VMWare virtual machine on a Linux host… and it broke. I can’t deploy my apps anymore (“check your hardware” message). I updated Tinybooter to 4.2.6.1 with success but I can’t download TinyCLR. I tried both MFDeploy and FEZ Config tools:
- When downloading firmware, MFDeploy reports an erase failure at sector 0x0801000
- When updating firmware, FEZ Config reports that the board is not ready for firmware update.
Both error messages show up after two minutes or so after starting download.
I tried two different USB ports, with or without external power source to power my Cerbuino Bee, erased the flash memory with DFuse. Nothing worked so far. Did not try on a native Windows installation yet.
Is this a known Cerbuino Bee firmware issue or is it really a bad sector in ROM ?
Regards,
Yves
@ InspectorGadget - I would check a native Windows PC first to rule out the VM on the Linux machine first.
@ InspectorGadget - As Aron suggested, you can try with a native system. I have just updated a new Cerbuino Bee one hour ago to netMF 4.2.6.1 and it works fine.
I didn’t update the tinybooter however (still 4.2.4), but I quickly checked the tinybooter file and it should be fine. The firmware update worked fine.
I still had to test on different USB ports. Some of the USB ports still report the same error.
Regards,
Famory
@ InspectorGadget - After updating the TinyBooter, did you set explicit rules for the USB Device as Linux sees it through VM? I know this is an option on VirtualBox.