Fez Hydra - DOA?

Sorry for the long post … I have been at this for some time.

I’m at my wits end trying to figure out my problem.

I had the complete Hydra kit installed and working perfectly. I’m using the
display and led’s from my Spider kit and had all kinds of programs running
and life was great.

Then I decided to build the source code to create my own .netmf image
(for various reasons this is important)

After following some posts on the forums I decided to upgrade to the source 4.2
and managed to do a build of the code (after a few fixes) and created
a valid image. I deployed this image to the Hydra board and again wrote
some programs in vs2010, deployed and ran them. The only catch at this point
was I had commented out a call to “OSHW_Configuration_LCD_Set” in HAL_GHI_OSHW_Hardware_LCDController.cpp
because the module that defines it does not compile.
The test programs all ran fine. I was not using the display because of the shortcut I took in the source.
Anyways I decided to take a stab at fixing this and created a release .netmf image from the 4.2 source
with my fix in the source code.

Deploying this image and running my test program caused an exception in lcd controller module.
I decided to create a debug image in case this may give me more information … then the troubles began.

While trying to deploy this image the hydra board became unresponsive. I tried all the techniques I could
find on the forums, boot with sd card, short pins 8-10, harsh language … nothing worked.
The lcd display would show the Fez Hydra message with boot version# and a time, then say something
like "Transferring control to #00008400 (or something like this I am doing this from memory)
then the screen would go blank.

I came across the tinyboot method of attaching a button to port 14 and holding this while resetting …
and bingo I was back in buisness. I managed to erase, reflash and I redeployed the original GHI .netmf 4.2 image.
All my test programs were working again and life was good.

Then I tried the modified .netmf I created with my lcd fix which caused the same exception and my hydra board is
again dead in the water. This time however the display stays all white all the time. None of the erasing techniques seem
to do anything. I have absoulutely no feedback when resetting the board. As far as I can tell the board is DOA.

Any ideas?
thanks

The board was working at some point so it is not DOA, dead on arrival.

I think what you are doing is great, digging into the source codes and compiling the firmware. But, you have to be careful with static and with grounds. The ground from your JTAG, your pc, maybe way off from the ground on the device, floating. This can immediately damage the processor. static discharge is another source of problems.

What you should try now is to complete wipe thd device blank using samba tool and them load our official firmware. If no luck then something you did, may not know it, caused thd damage.

Let us know how it goes.

My apologies, the board did in fact run fine for the last week and it was my tinkering
that caused a problem. I will check into samba and try that.

By the way - this is a great kit, Im really excited about getting into it.
My motivation is I’m putting together a gadgeteer/embedded workshop that I am going
to pitch to some local colleges. I believe there is a huge potential for teaching embedded
basics using this kit (and advanced as well!)

cheers and thanks for the advice

We are here ready to help whenever you need us :slight_smile:

Keep us updated please.

Unfortunately I am not getting any serial ports on my windows 7 box(64bit i7, 2.6GHz)
I read a post earlier about fast boxes and usb problems, was there any substance to this?

Anyways, without serial ports Samba is a dead end.

I’ll try taking the board out for dinner tomorrow, and maybe some flowers. If that
doesn’t work then I’ll get some more kits.

cheers

What about a virtual serial port via USB?

My understanding is that when you plug the fez hydra board
into the pc usb port the GHI usb drivers load which create a virtual
serial port on the PC side. This used to work just fine but not any more.
The virtual port is not being created. I’ve tried installing the GHI kit onto a
slower 32 bit laptop and same story. My spider board connects just fine to the
save PC’s same usb ports etc so its not a cabling or usb problem.

I’m fairly convinced I fried the board or a component on it while tinkering
with it. I have a friend with a logic analyzer, we are going to check for any processor
activity at reset.

If you boot into TinyBooter does it do anything different?

This involves attaching a button module to port 14
And pressing it while resetting?
Yes I have tried that, no difference.

Is there another method of booting tiny mode?

place a wire between MISO (socket #3 or #4 pin #8) and GND (socket #3 or #4 pin #10) then power up the board, wait 5 seconds and remove the wire. Do NOT leave the wire there for more than 5 seconds.

If that get’s you in then you should be able to reapply the firmware and be back in business.

2 Likes

Ok, fan me with a brick it worked.
I’m not yet sure why but I decided to make a new cable
to short the pins, did the procedure and bingo Im back in buisness.

Maybe it was the promise of dinner did it, maybe the planets aligned,
Im not sure, but thanks so much for the tips and help.

I will have to dig deeped into the lcd code and find the problem.
One thing I noticed:

in OSHW_Configuration.cpp at line#7

#ifdef FEZ_CERBERUS
OSHW_Configurations_Structure OSHW_Configurations;
#endif

so this only gets instantiated when the FEZ_CERBERUS symbol is defined, yet around line#13
return HAL_CONFIG_BLOCK::UpdateBlockWithName(OSHW_CONFIG_DRIVER_NAME, &OSHW_Configurations, sizeof(OSHW_Configurations_Structure), TRUE);

it is being used unconditionally.

The configuration library is also not included in the build project.

It looks like the configuration system is new and is not fully integrated.
This was the code I was trying to integrate in my .netmf version which I obviously botched.

Hope this helps.

Again … thanks for all the tips and help. Im glad I didnt fry the thing myself.

cheers

1 Like

This is why this forum is top of the league!

The reason for this line is to prevent issues with Cerberus as OSHW_Configurations is called because of LCDController code. Hydra’s call to this is in the AT91 LCD_9RL. Without the defining of the Cerberus Global call then the Cerberus will not compile. It is not really used for Cerberus but a global variable needs to be created.

@ Dale - Great! Glad you got it working. It’s pretty hard to brick a FEZ. It’s not so hard to corrupt the firmware on a Hydra since v4.2. I expect this will get better with v4.3 coming in a few months. This procedure should get you out of nearly any software problem you encounter if the Hydra becomes unresponsive.

BTW, welcome to the community! I’m eager to see the projects that result from your customized firmware.