#457

Sounds like this is saying it couldn’t find blank.bin in the folder where you ran the script, you may need to be in the same directory as the blank.bin file. This file is included in the crow firmware release bundles and is literally just 16 bytes of zeros to overwrite metadata about the script’s length / the state of user script flash, here you go: blank.bin (16 Bytes).

You can open your userscript.bin file downloaded from the module in most text editors, there is some extra binary stuff at the beginning and end but otherwise the contents of the file is crow’s lua script from flash. This looks like a pretty complicated script so it’s hard to say where exactly it’s crashing. Not sure what firmware version you’ve now flashed to but the development builds have some fixes for some of the most common crash scenarios (infinite loops, stack overflow, out of memory). You can find the development builds that completed successfully from this github feed.

1 Like
#458

Thanks, I’m on the v1.03 https://github.com/monome/crow/releases but still get a “crow disconnected” in Druid were previously v1.03 was working fine before the crash. That v1.03 had the blank.bin in the folder. So the only error I got from that v1.03 error was dfu-util: can’t detach after loading the firmware. I think I will try some of the development builds to see if I can get it to work. Thanks for the link, I wasn’t aware of those.

#459

Apologies for not giving much context here. The erase_userscript.command file needs to be run in bootloader mode – it is the same as flashing the firmware, except it is flashing some data (a few zeroes to disable the uploaded userscript).

The process is:

  • Force the bootloader by bridging the ground + middle pin of the i2c connection. keep these pins bridged.
  • Restart your modular system. Crow should now be in bootloader mode.
  • Run osx_linux-erase_userscript.command from the v1.0.3 firmware update folder.
  • You should see:
Download done.
File downloaded successfully
dfu-util: can’t detach
Resetting USB to switch back to runtime mode
  • Remove the jumper on the i2c connection.

Now crow should appear in druid with <crow connected>. If it still doesn’t, try restarting your computer. If there’s still trouble, we can try erasing everything on chip except the bootloader. Let me know.

Thanks for uploading the userscript.bin file! I’m going to flash it to my crow and see if I get the same crash. Apologies for having the permissions wrong & not explaining that it needs to be run from the firmware folder.

2 Likes
#460

Had to update my mac os to run the sweet new Logic sampler and it changed my terminal shell. Now calling druid gives me a zsh: command not found error. I can still run druid by clicking the finder file. I think its a path issue but I can’t figure out how to fix it.

– please ignore. I sorted it by doing this in terminal. I’m feeling very grown up!

path+=(’/home/david/pear/bin’)
export PATH

#461

OK this has worked :slight_smile:
Couple of key things i did differently than before, was the bridging.
Previously I bridged while powering up, to get to bootloader, then unbridged before loading up the dfu. It’s not clear in the docs how long to hold the bridge for (i was assuming just for boot up), but is very clear in your instructions.
So this time i used a real pin bridge jumper and only removed after the dfu had finished uploading.
After loading up and unbridging i was still getting a “crow disconnected”

I had to restart the computer and finally got a “crow connected” :slight_smile:
Thanks for you help and also to @csboling and @jlmitch5

#462

I’ve had a crow in a 7U 84HP case with a DIY power supply and had no issues with it.

Moved the majority of my rack into an Amalgamod 7U 102HP case with an Elby powered busboard (ED126 & ED123)


https://www.elby-designs.com/webtek/power/busboards/ed123/ed123-guide.pdf

The PSU is a 4MS Power Brick 90. (15V, 90W, approx 4.6A)

Everything else in the case works fine, but the crow does not seem to function. I first noticed the issue when druid showed a status of “crow disconnected”.

I thought I might not have plugged in the power ribbon correctly. I tried reseating the cable, no change. Tried several over outlets on the distribution board, no change. Tried taking several power hungry modules out of the case, no change.

The crow still works fine in the other case, so there’s no issue there. I set the crow to running First, and put it back in the new case to see if it would run there, even if it wouldn’t talk to druid.

Noticed that it was putting out 10V on all outputs.

Seems that there is something strange in the way the unit is being powered in the new case,

The old case has 5V supply, but the Elby does not. But crow does not need 5V right, so that shouldn’t be an issue.

Is it the timing of the power up, perhaps an issue during powerup with other modules being hungry?

If anyone else has seen something like this or has suggestions I should try, I’m all ears. I’ve double checked the polarity of the power cables during connection, so I’m confident it’s not that,

Very keen for crow to live next Just Friends and also take input from a 16n, so any suggestion is welcome.

Thanks in advance.

1 Like
#463

The outputs sending 10V indicates that the microcontroller is not starting up. This is most likely a power issue. Do you have a multimeter? If so there are 2 test points on the bottom of the crow PCB that should read +3.3V and +3.1V.

I’m guessing it has something to do with some kind of soft-start condition confusing the microcontroller…

#464

thanks @Galapagoose - I’ll aim to do a voltage test on the crow as you suggest. Elby has a module power delay component that sits in line with the power cable for an individual module - can delay power by up to 10 secs - may help in terms of separating the crow from the rest of the modules startup sequence.

(also thanks to the mods for relocating my question to the correct thread - much appreciated).

#465

I might have encountered a bug in the crow.connected() function with norns. It always returns false, even when crow is connected (and even outputing stuff). Can anybody verify this?
Cheers

1 Like
#466

Indeed, looks like a typo in this lua function. One-character patch submitted here.

1 Like
#467

Not sure if this is a thing or not: But after uploading a script I’ve been working on for the last few days, after a restart the crow refused to connect. Had to force the bootloader to remove the script in order to get it to behave again. I had added a very long comment line, ~520 characters. When I broke it up it seemed to start behaving again, though there was a some additional troubleshooting between, so maybe something else was actually at issue. Does crow not prune the comments when uploading a script?

#468

I noticed that the first line of a script (comment or not) gets sent as a druid message when the script runs, so it must be keeping the first line at least!

#469

That is also my assumption, based on the name being maintained as the first line comment. Seems like the rest could be stripped out? But if not, might cause an issue!

#470

Druid and crow should both leave the script as-is, I think the idea being that when you ^^print the uploaded script back it should show you the script in its original human-readable form.

I am guessing you are on the v1.0.3 release firmware? A few of the most common kinds of script errors that could previously have locked up the module have been fixed in development builds (obligatory caveat emptor). I’m curious if the issue you encountered is resolved but I don’t really see how long comments could be the culprit – the entire contents of script memory get passed to Lua to evaluate. Here is a test script that works correctly on a current build, in ‘run’ or ‘upload’ mode, in which the longest comment line is 1731 characters.

longcomment.lua 
-- longcomments
function init()
-- 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
  m = metro.init{ event = print -- 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
                , time = 1.0
-- 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
                , count = -1 -- 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
                }
-- 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
  m:start()
  print('ok')
end
#471

Hmm. Interesting. I am on 1.0.3. It is, of course, possible it was something else. I only added one other line, but that new line did not seem to cause issues upon re-uploading. Well in anycase, I just wanted to leave record of the weirdness in case it crops up again. Thanks for the clarification! :relaxed:

#472

I was hoping to be able to do something similar to output[n].action = lfo() using ii.er301.cv but no such thing appears to exist? What would I need to do to make something like that possible?

#473

I believe currently ASL actions are always associated to an output, you can’t really have them “free running”. I have still not really taken the time to fully understand how ASL is implemented but I believe that an ASL is sort of an array of “steps” to(volts, seconds, shape), which crow’s firmware uses to pre-calculate interpolated CV values for a particular output. You can’t really send I2C messages as fast as crow is updating its DAC. You can evaluate some Lua to determine the volts or seconds parameter though, so you can maybe sort of schedule occasional I2C messages this way:

function ii_to(dst, time)  -- 🩰
  return to(
    function ()
      ii.txo.cv(1, output[1].volts)
      return dst
    end,
    time
  )
end

function init()
  output[1](
    loop { ii_to(1, 0.25)
         , ii_to(2, 0.25)
         , ii_to(3, 0.25)
         , ii_to(4, 0.25)
         , ii_to(3, 0.25)
         , ii_to(2, 0.25)
         , ii_to(1, 0.25)
         }
  )
  print('ok')
end

This gives a steppy LFO from TXo output 1 that is sort of like sample-and-holding the smooth voltage that crow is outputting. Expanding on this idea you can generate the table of waypoints programmatically:

function ii_lfo(vmax, period, steps)
  local action = {}

  local midpt = math.ceil(steps/2)
  local v_step = vmax / midpt
  local step_time = period / steps

  for i=1,midpt do
    action[#action + 1] = ii_to((i - 1) * v_step, step_time)
  end
  for i=midpt,steps do
    action[#action + 1] = action[midpt - (i - midpt)]
  end

  return loop(action)
end

function init()
  output[1](ii_lfo(5, 2, 20))
  print('ok')
end

Lots of interesting functionality related to ASL is getting added in each firmware release, so there may be some other ways to do this kind of thing, either at present or in the future.

2 Likes
#474

The ASL stuff comes from a library that Trent has on his git repo - wrDsp I think. It seems quite deeply embedded right now and tied in with the hardware

I see no reason that this library couldn’t be implemented by the likes of TxO and even for ansible (except size of the flash considerations) but I suspect it would have to be client side

However someone could implement something in crow like adding to crow an ASL metro call back

asl_metro.init{ time=0.001,action={ to(6,1.0),to(0,1.0) } , function( asl_value ) ii.something.voltave(asl_value) end }

(excuse syntax errors in my rough code)

and obviously limit of II coms would a factor

There might be reasons for that not working of course which @Galapagoose will know better (like for example him not wanting to since it his code :slight_smile: )

#475

The atoms of ASL are to function calls. Beyond that, ASL is just a method of stitching them together in time (with some fancy looping / conditional options).

A to call is essentially an interpolation curve. Go from the current location to a new location over a certain time (following a given curve). At the moment it is linked directly to a DSP library controlling the output jack. I have an extension coming that will allow an ASL to control a generic variable.

I like the idea of using asllib-style helpers for ii commands. There could be 2 backends: 1) breakpoint style for modules that have ‘slew time’ built in, 2) streaming mode for just setting values continuously with some update interval param.

If anyone has proposals for syntax that’d be a good start. Maybe something like:

 — make an ASL
erlfo = Asl.new()

erlfo.to = ii.er301.cv — redirect ‘to’
erlfo.throttle = 0.1 — update every 100ms

— works like a normal asl
erlfo.action = lfo()
erlfo()
8 Likes
#476

Thanks for the tips @csboling, finally got a chance to try it, works!

Can you help me understand better the distinction between #1 and #2? I think I understand what #2 means, but I’m less clear on the meaning of #1.

Would love a way to output less steppy curves over ii.

The ER-301 I2C implementation current can accept either triggers or CV. I don’t think there’s much Brian from Orthogonal Devices could do to make ER-301 a better partner for crow, but if anybody has specific ideas there, I’d be curious to hear them.

Seems like a great start!