Hydra: Pulling pin 3 on socket 14 low prevents boot

Archive
1

I’m having an issue with my Hydra. I have designed my own motor module that has current measurement on a A type socket.

My board basically pulls pin 3 and pin 4 down with 100 ohm resistors. This prevents the Hydra from booting. It seems to get stuck in the bootloader.

I have also placed a joystick on socket 14. Pushing the joystick while powering the board prevents it from booting, same result, bootloader only.

Is this by design? This isn’t specified in the Gadgeteer module guide.

2

It looks like you ran into the same issue we ran into a while ago…see this post below:

http://www.tinyclr.com/forum/topic?id=6826

Not sure if GHI found a fix…

Cheers.

3

So it isn’t a new problem. Hopefully my post will add to the bigger picture and make the problem easier to pinpoint.

I suspect the bootloader looks at pin 3 on socket 14 and stays in Bootloader if it is seen to be low. I can see how this could be needed, but it should then be a separate pin, like on the Cerberus. Not on a Gadgeteer socket as that can just cause endless problems…

4

Just took a look at the relay module. It pulls pins 3,4,5,6 low through 10K resistors. Your problem is the same as my problem. There is a bug, or feature, in the bootloader that doesn’t like pin3 being pulled low…

5

Thanks for narrowing this down…
i hope GHI will investigate and report back…

6

@ GHI,

Also note that, with the board in bootloader mode(Tinybooter?), VS can still see the board and deploy to it happily. Your deployed application will run happily. But the board will only run after being deployed. Doing a reset or repowering the board will NOT run your deployed application. The board will seem dead. The led on the Hydra will light breefly, then die, but the application will never run…

7

I thought this is by design. We can remove it but then how can you force tinybooter if you need to?

Aron knows better about this

8

TinyBooter on Hydra looks at Pin3 on Socket 14 at powerup to decide if it should remain in TinyBooter mode at startup or continue to load TinyCLR and the user application. If the pin is at a low state then Hydra remains in TinyBooter mode.

TinyBooter needs a designated pin to force into BootLoader mode at startup. This will be usefull to update firmware or recover from a runaway user application.

To work around this you can change the Pin to something else in the WaitForTinyBooterUpload function on TinyBooterEntry.cpp, alternatively you can use a inline diode in the module (mabye through extender module) to prevent the relay module from pulling the line low during startup. I don’t know much about the relay module and the diode may not work.

9

A diode can prevent the pin from being pulled low, but it will also prevent the pin from doing anything else, like turning on a relay…

Gus, I think this pin should then be on a Z Socket, or on one of the pins on the D Socket of the Hydra.

I realise that such a pin is required, but putting that pin on socket 13 breaks the socket. It means that pin 3 cant be used for anything at all. You can’t use it as an input, if you can’t gaurentee that your input will be high during startup, and you can’t make it an output, because you will have to pull it low to prevent your output from turning on before MF is running to pull it low.

10

Errol,

Pin 3 was chosen because it is the pin that is used by the Button Module. We wanted to make it easier for the End-user to put the Hydra into bootmode, in case of a firmware lockup, by using a ready module instead of requiring the user to use an extender module and have to ground any random pin. As what Rajesh said, the pin can be changed to another pin 3 on another socket or even removed all together if you feel that you will not need to force TinyBooter. There really is not any other pin that can be used that will not potentially have the same result as with this issue. Socket 1 (Z) has the JTAG pins and the RTC and the Reset associated with it. Those pins cannot be used to force the Hydra into TinyBooter.

11

I understand why pin 3 was chosen, but using pin 3 violates the Gadgeteer specification. There is problems with two modules, that we know about.

In future, if you want to add something like this then it should be on a Z header.

How about this:
Make pin3 on the D socket so that, if pulled low then erase the managed application.

Then if the user must get into tinybooter then temporarely connect the USB module to another socket, connect a button to the D socket, and either reset the board or power up while pressing the button on D socket.