I have been programming this system for months, not using the ghi classes, for the Hydra.
I was attempting to get an analog channel to work - any analog channel - using plain netmf. Stuff right out of the book, but gave run time errors no matter what channel I chose. I chose Analog_None one time (big mistake) and since then:
Deploy tool won’t connect even though windows manager sees it. Can’t ping.
Tinybooter load program seems to work but doesn’t really.
It comes up with
ABORT Data ****
00:eaffff61
Aug 20, 2013
15:35:16
10:e59ff00c
cps=0x2000000df
pc =0x20122794
lr =0x20137cc
sp =0x0030f660
On the touchscreen. As near as I can tell, the unit is barely on life support.
Anybody have any ideas?
Thanks, Mark
@ markatwindwave - if you erase your device then reload the firmware it will work just fine.
Now to catch the issue that caused the crash, send us your code if you like and we will take care of it.
What you can do is as a piece of code at the very beginning to wait for a button press before executing the program. This was if this did happen then you can simply use the button to stop the program and then load a new program.
I can assure you what you saw is extremely rare and nothing to worry about.
I’ve tried your suggestions about 20 times with variations before I gave up and posted. I wish getting it back was that easy. Here’s what I did.
I grounded pin 8 according to the directions (last time I did this it was pin 9) and powered it up, waited more than 5 seconds, ungrounded, ran the batch file (which was in a different place than the documentation) and got the following log:
-I- Waiting …
-I- TCL platform : Windows NT
-I- SAM-BA CDC 2.10 on : windows
-I- Retrieved arguments from command line :
-I- argv 0 : at91sam9rl64-ek
-I- argv 1 : TinyBooterLoader.tcl
-I- argv 2 :
-E- Connection at91sam9rl64-ek not found
-E- Connection list : com1 com3
Device Manager showed it as a camera at com3
After a reset (tried both the button and powered down) and a power back up it showed on Device Manager as a FEZ Hydra on usb. It also displayed the stuff in the screen from the previous post.
Running FEZ config yielded a status of No Device. Trying to ping yields:
Failure - Device is not connected or not responding.
I am running plain Netmf on my Hydra and not using the GHI classes. So far I have about 30 modules written for a sophisticated ui, but I needed access to an analog pin.
All attempts failed, could not use GetSocket (no Hydra init), so I used the generic netmf SPOT interface. I was getting run time errors on all analog pins I chose except when I ran this single line:
Microsoft.SPOT.Hardware.AnalogInput x = new Microsoft.SPOT.Hardware.AnalogInput(Cpu.AnalogChannel.ANALOG_NONE, 10, 0.0, 10);
Now it’s toast.
I would be glad to send you the code, but it’s close to 10,000 lines.
Any other suggestions would be appreciated. I had no idea these were so fragile and fussy! Do you have another product that is more robust?
Thanks,
Mark
@ markatwindwave - you shouldn’t be worried, really. There is no possible way you can brick your board by loading the wrong software.
I do not think the first step worked, which erases the entire flash. So let’s take it one step at a time, after taking a deep breath we will make it work together.
After you short the wire and wait few seconds, you will see a com port on your pc device manager. Now is the setup that erases everything and flashes tinybooter. After this stage was done complete, your device will show as a netmf device again in device manager…and just then proceed. If not, do not bother going through further steps.
Did you right click and run the update batch file as admin? Take a screen shot of your prompt window please.
as Gus says, probably be fine here… let me add some more details though.
You are best starting an elevated CMD prompt manually rather than navigating to the file and trying to start the script - I think it’s more reliable and easier to see the output of any errors that may not show otherwise. Navigate tot he correct directory to run the install from and then start the script
If the device shows up as COM3 when you are holding the wire and resetting, that’s good. If you reset it without the pin, what appears in Device Manager ? That can also tell us what is going on with your device.
Another way you might be able to trick the device into life, assuming that you have a netmf debuggable device appearing in Device Manager is to create a new “flash LED” application, and start the deployment and then hit reset on the device.
Hi Gus and Brett,
I have gone through this procedure numerous times until I got desperate and came to the forum. The batch file to erase the hydra runs the same from an (administrative) command window as right clicking and running as administrator from windows explorer. It completes within a few minutes without any error messages, but the log file has two lines at the end I don’t like:
-E- Connection at91sam9rl64-ek not found
-E- Connection list : com1 com3
Does -E- mean error?
How about the “ABORT Data *****”" stuff on the touch screen of the hydra?
After a reset windows device manager changes from com3 gps camera to Fez Hydra with a usb connection.
Mfdeploy and Fezconfig both seem to work the same way. Bringing either one up yields nothing, but hitting the reset button on the hydra again will cause Fez Hydra to show up as a usb device. It will not ping though.
Exactly, you tried it many times but it never worked in any of them. This step did not succeed, I would not try anything else, not FEZ Config, not visual studio, until this step is complete.
What did you enter when you ran the batch file? COM3? come3, or just 3?
so in fact, because I can see you’re using a 4.2 DSK, you’re not following the procedure you need to. You need to start an elevated command prompt - GHI leave the “commandprompt.bat” item there for you to do that, or you can start the command prompt as you normally would.
You then need to run the updateFezHydra.bat command with the COM port you want to use. In your case the command you want will be:
UpdateFezHydra COM3
Capitalisation of the serial port name is important. I am pretty sure you need capitals but if that also fails try lowercase.
Then, happy days. The notepad view into the log file should show lots of erasing of the device then writing of the device
I didn’t mean to imply I had done the same thing 20 times. Each one was different. I think I managed to corrupt my tinyclr and it was still running, kind of. The usb interface was running too, kind of.
In case anybody else has this problem:
I had to open a command window and run updatefezhydra.bat com3. Com3 must be in lower case. Then I got lots of logfile messages.
After a reset, running fezconfig and checking the device for update showed that both the loader and tinyclr were up to date and matching but the clr needed to be rebooted. I did that and it said it was done, but it still didn’t work.
It was necessary for me to use the Firmware Updater to reload everything, then go back and reboot the clr, followed by a power down.
Brett - I’m not sure what documentation I missed on this one. I was following the instructions in the developer’s guide under the heading “Loader Update” that specify I right click the batch file and run it as administrator.
Happy days are here again. Thanks guys.
Now if I can just get to an analog pin…
Cheers,
Mark
Thanks guys. I was stuck. The instructions have changed and I didn’t notice.
Here’s what went wrong:
My program uses plain netmf, so there was no instance of the GHI mainboard class. Calling GetSocket(…) will return a run time error of invalid socket for every socket.
The SPOT AnalogInput channels for socket 14 pins 3,4,5 are ANALOG_5,ANALOG_2,ANALOG_0. Instantiating this class during the gui building phase of a program will generate a run time error of invalid channel for every channel. Netmf hasn’t set up everything under the covers until the application is fully running, so it takes an event like a button push, or a timer going off, or a hook (IsVisible works) before an instance of AnalogInput can be created. Then it works fine.
What screwed my Hydra up - partially crippling the firmware and requiring a complete reload - was creating an instance of AnalogInput during the gui building part of my program, and selecting channel ANALOG_NONE. Don’t do this.
Cheers,
Mark
we will make it work together.