Main Site Documentation

Update firmware Cerberus


#1

hi,
I tried updating firmware on mainboard Fez Cerberus.

TinyBooter:
I followed the instructions and had no problems.

TinyCLR: FEZ Config (1.0.1.0) recognizes the mainboard but reports “The device is not ready for update!”

and I can not continue.

can you help?

Thanks
Luca


#2

Fez Config “check device for update” reports
Loader (TinyBooter) Version: Not present on the device

but i’ve updated without problems with DFU Tester (v3.0.1)


#3

On what system are trying to update the firmware? Can you provide any screen shots that will illustrate the issue better?


#4

I’ve attached screenshot.
I tried it on a “virtualized” win 8.1 and on “genuine” win xp 32 and I have the same problem.


#5

“Create from Map” and “Erase” seem like it’d be the area to concentrate on. I’d suggest giving us a look at Device Manager when you reboot the Cerb, as it should show up in loader mode (can’t tell you from memory what that looks like though)


#6

@ luca_santoro - Two more questions:

  1. Can you try to ping from MFDeploy after the DFU procedure?
  2. Do you have a straight Windows 7 Machine you can try?

Also, what Brett said is very important to press “Create from Map” before erasing the memory.


#7

I do not have a pc windows 7, yes i’ve clicked “Create from Map” before erase.
After several attempts I updating firmware in windows xp with FezConfig(I have reset several times with Fez Config open).

Now when try to debug in visual studio i get:

Looking for a device on transport 'USB’
Starting device deployment …
iteration 0
Opening port \ ? \ Usb # vid_1b9f & pid_0102 # 6 & 32a5dfec & 0 & 5 # {a5dcbf10-6530-11d2-901F-00c04fb951ed}
Attaching debugger engine …
Debugger engine attached …!
Querying device assemblies …

Error check hardware and not works.


#8

So step thru the manual process again and describe what you see at each phase please.

Do the STDFU phase, and write the new loader. Then re-power the device and show us the device in Device Manager.

Open FezConfig and “Check device for update” and show us the result of that; then deploy the firmware.

I have stepped through this with an STM32F427 device on Windows 8.1 in the past week, without issues. It seems to me to be either your PC USB ports or drivers, or possibly even the USB cable you’re using. Are you sure you’re using a high quality, heavy duty, USB cable (I have some light weight, dodgy eBay purchased cables that are woefully unreliable, they aren’t worth cutting up for scrap !).


#9

I’ve tried on “genuine” windows 7 64 bit and update fw with fez config works fine, unfortunately on virtual machine win 8.1 (my mac) not works and on win xp 32
works badly.
Stm driver works well on vm win 8.1, tiny booter updates fine, instead ghi driver not works and fez config not updates firmware.


#10

What virtualisation software do you use? There’s known incompatibilities with one of the options here. You should do a search here for bootcamp and you’ll find the answer - which I think is that bootcamp works, but the other option doesn’t (sorry, I don’t dabble so have no need to retain that info :slight_smile: )


#11

My pc is a mac book with Parallels Desktop 9 and Windows 8.1 on virtual machine.
With the Fez Cobra 2 I have no problem as well as the Netduino Plus 2 works fine,.
I wanted to try the Fez Raptor but I read that on VM does not work, I thought Cerberus That would work fine but it does not work.
Honestly I’m perplexed why it does not work, so far on my virtualized Win 8.1 everything has always worked.

I would not use bootcamp because I would lose the convenience of the virtual machine.


#12

@ luca_santoro - Until the Raptor, I had no problems with Premium devices and VMs using Fusion. The Raptor was the first Premium device that I could not use with a VM.

I have never been able to get a OSHW device working with a VM. I have not tested any OSHW devices recently, but I believe the issues still exist.

VMs have been an open issue for several years. For Mac users, bootcamp has been the resolution. Given that an workaround exists, VM support has not been a high priority at GHI. It is on their list of tasks, but I would not depend upon it being resolved in the near future.

Bootcamp may be inconvenient, but it is a lot better than not working.