seem to have bricked my crow after a very gentle less concepts session. bootloader unresponsive, even shorting the pins doesn’t work.

image

usb device not recognized. I’m on windows unfortunately. any ideas? is there is super secret reboot procedure?

so, trying connection via an rpi now. lsusb shows no device:

patch@patchbox:~/Desktop/crow/crow-v1.0.0 $ lsusb
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Well, dang. I was having great success, having gotten everything setup and working with Bowery scripts and Less Concepts for Druid. But then I uploaded shiftregister.lua from Bowery and it locked up Druid bad. Now after rebooting/restarting everything, Druid doesn’t see crow, nor does command center in M4L. Any ideas? I am completely dead in the water. Thanks in advance for any assistance you can provide.

on the move, but see last paragraph here: https://monome.org/docs/crow/technical/

confirm success or further trouble?

1 Like

Nope that did it! Forcing bootloader with a cable tip was a bit daunting but it did the trick, thanks @dan_derks!

1 Like

This is what you see on raspi when you force the bootloader (short the i2c pins on startup)? I just had Windows start giving me very similar behavior and had to force the bootloader and erase the user script from flash, after which I’m back in business. When you force the bootloader I expect dfu-util -l to give some output like this:

$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=58, cfg=1, intf=0, path="1-9", alt=0, name="@Internal Flash   /0x08000000/03*016Ka,01*016Kg,01*64Kg,03*128Kg", serial="304F35573137"

thanks for looking into this! I do not see any device when i run dfu-util -l. I get the dfu-util 0.9 startup message, but no device listed. :confused: lsusb shows nothing either.

after the umteenth time plugging and replugging between windows and pi, the device eventually registered on windows, and i redid the windows driver and firmware update procedure as described above. however, i still get the usb device not recognized error, and on the pi, dfu-util still doesn’t see the device.

druid reports no crow device.

i’m on windows 7 btw, could this be a factor?

Did you do the erase_userscript.sh procedure too? I had the same situation where I reflashed the firmware and windows 10 was still giving a “warning: unknown usb device” notification, so I needed to force the bootloader again and run the erase_userscript.sh script - evidently the firmware was fine, but something had happened to the script on the device that made it crash as soon as crow started up and tried to load the script. I’m not sure yet what causes this but am looking into a couple script upload related problems. You said this happened after using Less Concepts, did crow just suddenly crash / disconnect while you were playing? Or it was all fine and you shut the case down, and then crow started doing this the next time you powered up?

1 Like

crow crashed during play, and went totally unresponsive. I did not run erase_userscript.sh. It’s way late here, but i will try that tomorrow. thanks :slight_smile:

ok. crow seems to be back up and running. thanks for all your help @csboling!

am i the only user on windows? Seems like there is something badly wrong with the windows driver set up. Why would a script cause the device to be not recognized?

Some kind of automatic routine that sets a hardware flag or something on crash and then forces first.lua on reboot should be implemented I think. Is something like this possible? Shouldn’t have to go through a user upload procedure to reload default state IMO.

Also, is there some kind of dfu-util log that i can extract in order to help further diagnose these issues?


Idea: force bootloader by a specific combination of dummy jacks plugged in to inputs or outputs and/or a high voltage on an input(s).

I note crow can read when a jack is plugged in. maybe dummy jacks in some combo of outputs to force bootloader?
image

For example, plug two dummy cables into outputs 2 and 4 with other jacks unplugged and power cycle case to enter bootloader mode.

2 Likes

So did I get this right, the topmost pin, which is partially under the white part in this picture would be GND, followed by SND and SCL?

indeed, WHITE is GND. all of the 2x3 headers have the same pinout, as they were (at some point) intended to have ribbon cables connecting them.

1 Like

This is the back of my Just Friends, showing, from the top to the bottom: GND (white stripe), SCL and SDA…

Sorry for the not great photo…

1 Like

Thank you! Good to know that all the versions of the module don’t have GND/SCL/SDA marked :slight_smile: These two photos might help some other strugglers out in the future as well.

[edited the pin order]

1 Like

Note that the order from the top is GND / SCL / SDA, and NOT the way you are describing them.

It is possible that it doesn’t matter about anything other than GND, at least while in the monome ecosystem. if I have this correctly, all the monome/mannequins should be the same, as they were designed to work with the 3-wire headers, but now more manufacturers are making i2c implementations and more folks are using single wires (like I am).

You may want to be super clear on which pin-out is which if going outside that ecosystem. I have seen something on lines that I can’t point you at the moment to that may have indicated that not everyone making i2c-capable devices has the pin-outs in the same position. So caution is warranted…

Hope that helps!

To my knowledge the only ones that use a different pin ordering are earlier ER301s and the Matrixarchate. Not sure about the Tetrapad hardware (there is not support yet for using any I2C leaders with Tetrapad besides the official Tetrapad expander).

There are a couple of us out here, including myself and I think @voidstar? (based on some screenshots of Powershell + Github activity) Glad you were able to get this to work, are you using druid successfully also? I hit lots of gotchas in all the setup for Python and drivers and stuff, though there are more hoops to jump through to have a development environment for druid.

Yeah, this sounds pretty reasonable, it’s just potentially a tough problem. If an uploaded Lua script freezes on startup, crow can become unresponsive as soon as it tries to load the user script. Then since it’s frozen during Lua evaluation (presumably?) the script can’t be reverted, so it’s still in flash, so it’s still what gets loaded on startup. A timer or something could periodically check if the script is hanging, but how should crow decide when a script is stuck? In some cases this may be hard to determine conclusively.

This does seem like potentially a lot less hassle than taking the module out of the rack, but I’m not sure how you distinguish a situation like this from something that might have been left patched intentionally.

Right on, thanks for correcting! I’ll edit my previous post so no one reads misinformation later on.

1 Like

One thing I’ve been doing during development to avoid this kind of thing is to use r instead of u to send scripts. Then, if something gets borked, it won’t try to reload after a power cycle.

4 Likes

Another windows user here. :raising_hand_man: Was having trouble getting up and running with druid until I found this https://docs.google.com/document/d/11Bnly-JOBh4_mWSyIGmEIpE_YO-6VH179KSHEWTZr2M/edit somewhere here on lines, now seems to be working okay. Might want to consider updating the docs for Windows users because many of the commands in the docs just don’t work with the way you have to do things in Windows. Without this external guide I was completely lost.

2 Likes

earmarked for tomorrow morning’s tasks, apologies all!

2 Likes