Main Site Documentation

Cerbuino Bee broken?


#1

Hello All,

I’ve been working with a Cerbuino Bee for a short while. The last thing I tried was to use SignalCapture to work with a SR04 ultrasonic sensor.
It deployed fine, but debugging didn’t work. Since then, I haven’t been able to do connect with the Cerbuino anymore.

This is what Visual Studios says…

[quote]Looking for a device on transport 'USB’
Starting device deployment…
Iteration 0
Opening port \?\usb#vid_1b9f&pid_0102#6&26c823&0&5#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Attaching debugger engine…
…cannot attach debugger engine![/quote]
What I’ve tried:

  • FEZ Config software shows a “Cerb-Family (non-commercial use)_Gadgeteer” device on the USB port, but I cannot ping it, checking for a new firmware also ends with an error message that it couldn’t connect.

  • MFDeploy doesn’t list any devices.

  • Same for the STDFU Tester which also doesn’t show any devices.

I’ve also let the board without power for an hour, and tried it on several USB ports and PCs.
Any ideas what to do, or is it just broken?

Thank you!
Johannes


#2

@ Trias - Did you follow the instructions for putting the Cerbuino Bee in bootloader mode before testing with STDFU?

If something in your code is making the board hang (infinite loop, etc.), the debugger may not be able to get the mCu’s attention to connect.

You can also try resetting the board while VS is attempting deployment…might be able to get it to connect before the problematic code is executed.


#3

@ Trias - Also what version of the SDK and firmware are you running? As Devhammer says do you have a tight loop in your code that is holding things up? Maybe post a bit of it using the code tags in the post editor (the little 101010 icon)


#4

@ Trias - Start the debugging, then while VS is waiting to connect, press and release the reset button. Try several times; sometimes my bee does this when I have it doing alot of work before start-up. It’s a good idea to put a short pause in the main : Thread.Sleep(1000)
This is to give the debugger thread time to connect to the host pc.


#5

Thank you for the quick replies!
The tight loops could very well have been the problem, I did some edits since trying to troubleshoot the code so I don’t have the original anymore.
As devhammer mentioned the bootloader mode (which I overlooked) I tried to follow the steps to update the loader (https://www.ghielectronics.com/docs/46/fez-cerb-family-developers-guide) - that worked fine, however after a reset there doesn’t seem to be a USB connection anymore (i.e. no driver loaded, no “USB sound”) though it still gets power.
The Fez Config therefore also doesn’t find any device.
I was running the most recent version (4.3?)

But it’s good to see that it now shows up in the DFU tester, maybe it’s not gone and I’m just missing a necessary step to get it to work again.
Any ideas?

Thanks!
Johannes


#6

@ Trias - You might just want to re-flash the loader, and then update the firmware from FEZ Config.


#7

So, the current state is…
If I use the DFU Tester (Erase and Upload) the Cerbuino doesn’t show up when I connect it to the laptop. If I upload the DFU file via the DFUse Demo software it seems to work.
It shows the Cerbuino in the FEZ Config utility, but still cannot even ping it, nor upgrade the firmware.
Is the “bad” program therefore still in the memory? Is there any other way to wipe it?
I tried the press and release from Mr. Smith, but unfortunately it didn’t help.

Will continue trying, but am grateful for any more suggestions!
Thanks!


#8

@ Trias - Is the device receiving sufficient power?


#9

Should be fine, no attachments at all, powered via a USB3 port.
I can try an external PSU tomorrow if you think that it could make a difference!

Thanks!


#10

@ Trias - Be sure you are following the loader update instructions to the letter. If you switched to the protocol tab once the device showed up in STDFU Tester, and clicked Create from Map, then Erase, the next step would be to click Load from DFU, select the 4.3 loader file, and then click the Download radio button (not Upload), and click Go.

That should update the bootloader, at which point you would reset the board, and it should show up in FEZ Config, and you should be able to update the firmware.

If you’re connected via a USB hub, try connecting directly to a USB port on your PC, and make sure you don’t have any modules or other peripherals connected to the Cerbuino Bee.


#11

Hello All,

Thank you for your support!
I was ready to assume that the Cerbuino was bricked while it was really just a too tight loop, as per your suggestions.
I found a part of the code that was running on the Cerbuino and, by quickly triggering the pin from where SignalCapture was reading, “distracted” the Cerbuino for long enough to upload another program.
Is there any safe way to avoid that in the future?

Again, thank you!

Best,
Johannes


#12

suggestions are to put a “wait” loop at the start of your app, or only proceed after a button press has occurred - waiting for 5 seconds is usually enough to let the debugger attach.


#13

I like to put a check for a button press at the beginning of a program. If the button is depressed, then I issue a Thread.Sleep(-1). If the button is not pressed, execution continues normally.


#14

These are excellent suggestion, will keep them in mind for the next project!
Thanks a lot!