Cerebuino Bee not recognized as USB device any longer

Archive
#1

So i finally got things working with the Cerebuino Bee after upgrading the clr and life was good…but this was short lived.

I was able to upload and test a few programs just fine. on the forth try, where i uploaded a program to try and tinker with led1 (by trying to guess what the pin might be), the upload froze. After that, my system no longer is recognizing the Cerebuino.
-MF Deploy shows no connected device.
-if i unpug and plug back in the Cerebuino…windows says something to the effect 'One of the USB devices attached to this computer has malfunctioned and that it can’t recognize it"
-I tried reinstalling the the software GHI software/sdk to repair the installation (and which re-installs the usb drivers)…but that did not help either.
-I tried starting my system to no avail…

Interestingly, If i plug the FEZ Spider in, it is recognized, but if plug the Cerebuino in, it is not.

Any thoughts on what might be going on here?

#2

I’ve not seen this on mind but do occasionally get a hardware error that prevents deploymnet. Even powering on and off, reest button etc didn’t fix it. I redepolyed the firmware and config using MFDeploy (it took several goes as the H/W locked up) but it all seems fine now.

#3

Did the same…erased and reloaded the firmware and now seems fine. something doesn’t feel right given that you’ve experienced the same issue also…but glad its working for now. lets hope this isn’t something we have to do often.

im trying to figure out the pin value for the leds, do u know what they are?..i think the docs may be in correct…the show the led above the input mini-usb connection as “configurable”, but the board list it as “pwr”. the led labeled “led1” seems like it might be the configurable one.

#4

I’ve honestly not looked at it that closely yet. I’ve been (as you know since you help me out) concentrating on extending the device beyond the few modules I’ve bought. IfI get some time I’ll take a look and see if anything makes sense to me. Good luck and let me know how you get on.

#5

Led1 looks configurable and according to the schematic it is on Pin 28. However, the following code does not power it on.


   OutputPort p = new OutputPort((Cpu.Pin)28, true);
   p.Write(true);

I got the schematic from here http://www.ghielectronics.com/catalog/product/351 and Pin 28 (PB2) goes to the LED. My code might be wrong as I’ve not gotten into doing this stuff yet. As could the schematic…

Hope that’s of some use.

#6

@ jamesjl - true this

Mainboard.SetDebugLED(state);

or

GHI.OSHW.Hardware.FEZCerbuino.Pin.Digital.LED1
#7

so for the bee use the following

GHI.OSHW.Hardware.FEZCerbuino.Pin.AnalogIn.A0;
GHI.OSHW.Hardware.FEZCerbuino.Pin.Digital.D9;

etc

#8

Thanks james and justin. not having much luck, maybe the GHI guys will chime in…

the code i’m using is:

28 - does nothing
Digital.LED1 - throws an exception.
D9 - does nothing…

#9

Try 18.

#10

How did you arrive at 18? Is there any document that maps pins numbers to IC pins? The schematic has PB2 wired to LED1. PB2 is IC1 pin 28.

Many thanks.

#11

Check my reply in this thread

http://www.tinyclr.com/forum/topic?id=8549&page=3#msg84813

#12

Curious to know why the pin numbers when they all have enums…

#13

Did not work…exception is thrown when trying to create the OutputPort

[quote]
Microsoft.SPOT.Hardware.Port::.ctor
Microsoft.SPOT.Hardware.OutputPort::.ctor
GadgeteerApp2.Program::ProgramStarted
GadgeteerApp2.Program::Main[/quote]

I tried looping from 0 to 50, creating and reading from ports, to try and figure this out…
0-8 throws exception when trying to read
9 bricked the thing again and forced me to Erase/Reload firmware and clr.

This feels like it is more difficult than needs to be. documentation would be very helpful in this case i think.

#14

Your using 4.2 framework and referenced the ghi DLL?

#15

Yes and yes. but in this case, i am just t trying to create a Microsoft.SPOT.Hardware.OutputPort for the configurable led on the board (so i’m not using GHI wrapper classes right now):

The difficulty i think we’re having is the labels on the board aren’t easily translatable into the ‘real’ pins your supposed to use. the schematics doesn’t seem to help much more either…on the other hand, im completely open to the possibility that i could simply be doing or interpreting something incorrectly here.

#16

@ ISuck@ Starcraft2 - Paste your full code to see if anything sticks out.

#17

I think i figured out the issue. First Architect is right, the pin is 18. The reason it does not work for me however is because the FEZCerbuinoBee class already opens an OutputPort bound to that pin. i am guessing you can not initialize two different instances of a port bound to the same pin.

I came to this conclusion after creating my own Gadgeteer.Mainboard and implementing the bare minimum required abstract methods:

[quote]public class MyMainBoard : Gadgeteer.Mainboard
{
}[/quote]

and in Program.generated.cs replace:

with

When i did this, i am able to deploy the same code that attempts to create an output port against pin 18 and toggle it on/off…it works.
if i switch back to using the .Gadgeteer.FEZCerbuinoBee() mainboard class, it does not.

So i think FEZCerbuinoBee is already creating that output port 18 and the framework doesn’t allow u to create another instance against the same pin.

does that sound reasonable? I guess we will chalk this up to “expected behavior”…

#18

Yep, expected behaviour. The reason it’s there is to protect the uC and the device on the end of a pin. If you define it in your app somewhere as an input or output port, and then later try to define it again potentially differently, you could be in a situation where you damage something.