Interrupt while deploying error

In another forum, someone stated that if code signing is not used, then signature files are not used, so the signature error can be ignored.

If so, the upload of config.hex and firmware.hex are actually working. This leaves me with the failing firmware2.hex upload at about the 60% mark, regardless of the tool I use.

I think this new Spider has a bad memory chip and the write operation just blows up at the same address each time.

I’m going to send it back.

Gus, willgeorge – thanks again for having tried to help earlier.

Louis

I don’t think it has bad memory!

Let me know what is your device status now?

When you connect to PC, show me what do you see in PC Device Manager, then I will try to show you next step!

Dat – here’s the information:

Hardware: Spider with USB Client DP in socket 1, 12VDC wall wart power.
Dip switches on Spider: All OFF

Pictures: Device Manager, with Spider unplugged and plugged-in.

From what I can tell, the entry for the Spider is under Debuggable .Net Micro Framework Device / GHI .NET Micro Framework USB Debugging Interface.

It is under these running conditions that I have been running Fez Config and MFDeploy (4.2).

Hope this helps – cheers!

Louis

Apologies – the attached picture for Device Manager with the Spider unplugged should look like this. The previous post had the same picture twice (with the Spider plugged-in).

Cheers,

Louis

Well fellas, it is now working…

Thanks @ andre.m for the tip on MFDeploy needing to match the current firmware. Based on your tip, I assumed MFDeploy 4.2 was also no good for a non 4.2 board. So I used an old MS MFDeploy I pulled from Microsoft to manually upload Config, firmware and firmware2 and they all worked (ignoring the signature error). Firmware2 did not die at the 60% mark anymore.

However, I’m not sure if this step was useful since the board still had the old 4.1 loader and a bad TinyCLR (according to FEZ Config, which indicated “Not available” or something).

Based on the tip from Dat, I focused on what Windows reported in the Device Manager when the Spider was in “loader” mode. One thread in the community indicated that other users (also w/ Windows 7 64-bits) were having USB device recognition problems, and needed to retry many times before a proper recognition.

So I went to the legacy updater FEZSpiderMainboardUpdater.exe. I switched the board to “loader” mode and reset it repeatedly until Windows recognized it this way in Device Manager:
COM12, GHI Boot Loader Interface
With this done, FEZSpiderMainboardUpdater.exe was able to push all files successfully.

Loader (TinyBooter) Version: 4.2.10.0
Firmware (TinyCLR) Version: 4.2.10.1

The Spider board now accepts an app compiled for 4.2.

Thanks Gus, Dat, andre.m and willgeorge – we’re now cookin!

Cheers,

Louis

I have observed the same error using FEZConfig_v011 on EMX last friday. Surprisingly, using the GHI_NETMF_Configuration_Tool_v003 and targeting 4.2 firmware was updating fine without any error…

I was getting the same error on my FEZ Spider until I updated the firmware.I was not able to flash the firmware using MFDeploy 4.3.0 or FEZConfig v013. Downloading the previous utilities allowed me to flash to 4.2 via FEZSpiderMainboardUpdater.exe dated 28 Nov 2012. Once the firmware was updated, I was able to ping the board and get a full properties report from both FEZConfig and MFDeploy.

Also, I am using Visual Studio 2012 Express with NETMF 4.3, so I had to manually set the application target framework to 4.2 instead of 4.3 to successfully deploy to the target.