#155

I have this issue as well when running norns scripts on crow. It does not work until I restart both. Sometimes I can get it to catch by changing the output on the norns app to something other than crow, and then back to crow…

2 Likes
#156

I am wondering if this has to do with the i2c chain order? My crow sits between my TT and Just Friends. Is it possible that TT is grabbing JF at power up? I am new to TT, is there a script I could execute sans keyboard to release control of the JF (if that is indeed the issue)? Not sure what order to power up, start things should be but it takes a lot of fiddling to get the connection made.

#157

I’ve only used crow a few times…but i experienced norns - crow connection issue when powering up crow with norns already plugged in. I was able to connect by plugging norns in after starting crow. I’ve only got JF connected so i don’t think it’s related to i2c order.

1 Like
#158

good to know, I will test that. thanks @ado

#159

I’ve only got JF plugged in to Crow as well

I do have multiple USB devices connected to Norns on the other hand

#160

Little help? Out of my depth on this question about i2c bus voltage (I do not have a crow)

Since crow’s pullups are configurable in script, does that mean the i2c bus has voltage all the time? Or only when the pullups are configured on?

#161

only when on. the pullups default to off.

A user's guide to i2c
#162

I have a question - i have an older mk1 version of Teletype and require a powered bus as am starting to include multiple i2c modules in the chain. If I now include Crow in the loop, does that count as an i2c powered bus? or would I still need a separate powered bus / backpack.

Edit - ignore that, I found the answer - Some i2c devices provide power/voltage (and pull-up resistors) to the i2c bus and others do not. Teletype and crow are the only monome modules that directly provide power to the i2c bus. So if you’re using other modules aside from Teletype or crow, then you will need an external power source to make the i2c bus work.

I know my older Teletype won’t have the i2c power so Crow helps me out of a situation

4 Likes
#163

Apologies if this a silly question… do I need a Norns to be able to use the ansilble commands in Crow? Per https://monome.org/docs/crow/norns/

crow.ii.ansible.*
#164

@mlogger TT actually does have pullup resistors, but they are just a little weak. you can have crow’s pullup resistors on at the same time for some extra range if you’re connecting more devices.

no need for norns, you can use ansible from crow directly, see https://monome.org/docs/crow/reference/#ii and type ii.ansible.help() into druid

3 Likes
#165

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?

#166

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
#167

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.

#168

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

confirm success or further trouble?

1 Like
#169

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

1 Like
#170

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"
#171

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?

#172

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
#173

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:

#174

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