#1

I’ve been working on some firmware for the whitewhale, and I’ve run into a peculiar issue when connecting an m64.

If I compile the most recent version of the white whale firmware from source, my 128 kit will be detected and work as normal. If I plug in my m64 I see the initial led pattern, but the unit doesn’t respond to key presses. I downloaded the most recent compiled release (1.5) and uploaded it to the white whale and it works fine on both the 128 kit and the m64. I’m curious if this is an issue with something in my environment, I’ve tried checking out older versions of libavr but haven’t been able to get it working with a version compiled on my machine.

#2

you’re on mac os with no compile or flash errors?

i just tested the most recent github version, both gs64 and vari 64 both work.

try doing a new checkout of the repository.

#3

Wiped out my libavr tools, did a fresh compile/flash and got this for the output:

clouds:src dsutton$ make
CC      ../src/main.o
CC      ../libavr32/src/adc.o
CC      ../libavr32/src/events.o
CC      ../libavr32/src/i2c.o
CC      ../libavr32/src/init_trilogy.o
CC      ../libavr32/src/init_common.o
CC      ../libavr32/src/monome.o
CC      ../libavr32/src/timers.o
CC      ../libavr32/src/usb.o
CC      ../libavr32/src/util.o
CC      ../libavr32/src/usb/ftdi/ftdi.o
CC      ../libavr32/src/usb/ftdi/uhi_ftdi.o
CC      ../libavr32/src/usb/hid/hid.o
CC      ../libavr32/src/usb/hid/uhi_hid.o
CC      ../libavr32/src/usb/midi/uhi_midi.o
CC      ../libavr32/src/usb/midi/midi.o
CC      avr32/drivers/adc/adc.o
CC      avr32/drivers/flashc/flashc.o
CC      avr32/drivers/gpio/gpio.o
CC      avr32/drivers/intc/intc.o
CC      avr32/drivers/pm/pm.o
CC      avr32/drivers/pm/pm_conf_clocks.o
CC      avr32/drivers/pm/power_clocks_lib.o
CC      avr32/drivers/spi/spi.o
CC      avr32/drivers/tc/tc.o
CC      avr32/drivers/twi/twi.o
CC      avr32/drivers/usart/usart.o
CC      avr32/drivers/usbb/usbb_host.o
CC      avr32/utils/debug/print_funcs.o
CC      common/services/usb/class/msc/host/uhi_msc.o
CC      common/services/usb/class/msc/host/uhi_msc_mem.o
CC      common/services/spi/uc3_spi/spi_master.o
CC      common/services/usb/uhc/uhc.o
CC      common/services/clock/uc3b0_b1/sysclk.o
AS      avr32/utils/startup/trampoline_uc3.o
AS      avr32/drivers/intc/exception.o
LN      whitewhale.elf
SIZE    whitewhale.elf
whitewhale.elf  :
section                size         addr
.reset               0x2004   0x80000000
.rela.got               0x0   0x80002004
.init                  0x1a   0x80002004
.text                0x878c   0x80002020
.exception            0x200   0x8000a800
.fini                  0x18   0x8000aa00
.rodata               0x8e8   0x8000aa18
.dalign                 0x4          0x4
.ctors                  0x8          0x8
.dtors                  0x8         0x10
.jcr                    0x4         0x18
.got                    0x0         0x1c
.data                 0x55c         0x1c
.balign                 0x0        0x578
.bss                 0x1938        0x578
.heap                0x5150       0x1eb0
.comment               0x2f          0x0
.debug_aranges       0x1368          0x0
.debug_pubnames      0x29b2          0x0
.debug_info         0x2ec63          0x0
.debug_abbrev        0x5eb7          0x0
.debug_line         0x184a4          0x0
.debug_frame         0x3534          0x0
.debug_str           0x9f16          0x0
.debug_loc           0x88f4          0x0
.debug_macinfo    0x1728834          0x0
.stack               0x1000       0x7000
.flash_nvram         0x7c8c   0x80020000
.debug_ranges        0x1b30          0x0
Total             0x17abcdb


   text	   data	    bss	    dec	    hex	filename
 0xb2aa	  0x570	 0xf718	 110386	  1af32	whitewhale.elf
OBJDUMP whitewhale.lss
NM      whitewhale.sym
OBJCOPY whitewhale.hex
OBJCOPY whitewhale.bin
clouds:src dsutton$ ./flash.sh
Checking memory from 0x2000 to 0x3FFFF...  Not blank at 0x2001.
Erasing flash...  Success
Checking memory from 0x2000 to 0x3FFFF...  Empty.
Checking memory from 0x2000 to 0xB9FF...  Empty.
0%                            100%  Programming 0x9A00 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x3E000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  Success
0x9A00 bytes written into 0x3E000 bytes memory (15.52%).
clouds:src dsutton$ git rev-parse HEAD
8acebe92b926b7e503b0158e81e4788bbd64b2ea
clouds:src dsutton$ cd ../libavr32/
clouds:libavr32 dsutton$ git rev-parse HEAD
7f412663eb97c6e7ac3aa4f78101215191349802

unfortunately it still does not work with my m64.

#4

@tehn would it be possible to upload the whitewhale.hex you generated? i can test with that and if it turns out that works, try and debug my environment more thoroughly.

#5

So haven’t had much free time to debug this as of late. Tested a little bit this evening and noticed that the builds I generate on my Linux/OS X box all end up writing 0x9A00 bytes, but the binaries that are provided via the releases on github writes only 0x8C00 bytes. I’m not sure if that really indicates anything super obvious, but I’m curious if anyone has suggestions as to why that might be happening?

The weirdest thing to me is that my varibright 128 kit works fine with both the 0x8C00 and 0x9A00 byte version, like what’s in those extra 3584 bytes that’s causing this?

#6

@tehn shot in the dark but is there any possible difference between the gs 64 monomes and the original m64 series? I’m talking like m64-0003 here.

#7

all gs64 are the same. mine works fine. have you tested the grid on a computer to ensure it works?

#8

Yep works fine on my computer and the old pre-packaged 1.5 release firmware works fine with the 64. So far I’ve tried compiling the firmware on OS X using the libavr git repo and on two separate ubuntu boxes using the atmel provided binaries and gotten the same results where the whitewhale.hex is 0x9A00 bytes large.

#9

@tehn, sorry to be such a pain. but would it be possible to compile/flash the firmware to double check the size of whitewhale.hex with a more recent version of libavr? what i’m trying to determine is if the compiled .hex file is the same size as the one i’m having issues with or if it’s smaller like the working 1.5 firmware.

also, would an avr programer like this: https://www.pololu.com/product/3170 work for ttl serial debugging?

#10

Got the uart serial connection working! Uncommented some of the connection init print_dbg statements.

When connecting my m64:
no calls to connect

# serial output for m64
// white whale //////////////////////////////// 31884 3976 8
 read preset 0�

When connecting my 128:

# serial output for 128 kit
// white whale //////////////////////////////// 31884 3976 8
 read preset 0
 uhi_midi_install ignoring descriptor; type: 0x00000002
 bLength : 0x00000009
 bInterfaceNumber : 0x00000000
 bAlternateSetting : 0x00000000
 bNumEndpoints : 0x00000002
 bInterfaceClass : 0x000000FF
 bInterfaceSubClass : 0x000000FF
 bInterfaceProtocol : 0x000000FF
 iInterface : 0x00000002



 uhi_midi_install ignoring interface; class: 0x000000FF ; subclass: 0x000000FF
 got unexpected byte count in response to mext setup request;
6044 77 204 250 175 214 77 255 255 255 255 0
 monome vari: 16t /////////////////

It’s a bit late to dig into this right now, but I should have a bit more in the coming days. Curious if there’s anything obvious right off the bat, going to try and put some debug in libavr to figure out if any connect code is called at all.

#11

Ripped out the midi functionality in a branch of the current HEAD of whitewhale and I’ve turned on more of the debugging. This is the output of what happens when I connect in a few diff scenarios:

m128 (which works normally):

 mode change (ignore)
 finished monome class init

// white
 usb vbus change, new status: 1whale //////////////////////////////// 31884 3976 8
 read preset 0
 timer_add, @ 0x00000618 ; timer is unlinked  ; list was empty  ; added timer as sole element  ; added timer to tail ; new count: 1
 timer_add, @ 0x000005BC ; timer is unlinked  ; added timer to tail ; new count: 2
 timer_add, @ 0x00000590 ; timer is unlinked  ; added timer to tail ; new count: 3
 usb device connection: 00000A9C , 1
 run uhi_ftdi_install
 ignoring descriptor in ftdi device enumeration
 class/protocol matches FTDI.
 completed FTDI device install
 changed FTDI connection status
 usb enumerated: 00000A9C , 00000000
 FTDI setup routine
 sending ctl request for serial string : 
 serial string: m0001750
 setup mext device
 setup request ftdi read; waiting...
 waiting for transfer complete; busy flag: 0 done waiting. bytes read: 6
 monome 128
done waiting. bytes read: 33
data:
 setting monome functions, protocol idx: 2
 posting monome connection event.  device type: 0 cols : 16 rows: 8
 connected monome device, mext protocol
 monome vari: 16t /////////////////
 timer_add, @ 0x00000578 ; timer is unlinked  ; added timer to tail ; new count: 4
 timer_add, @ 0x00000634 ; timer is unlinked  ; added timer to tail ; new count: 5

m64 plugged in when turned on:

�
 mode change (ignore)
 finished monome class init

// whit
 usb vbus change, new status: 1e whale //////////////////////////////// 31884 3976 8
 read preset 0
 timer_add, @ 0x00000618 ; timer is unlinked  ; list was empty  ; added timer as sole element  ; added timer to tail ; new count: 1
 timer_add, @ 0x000005BC ; timer is unlinked  ; added timer to tail ; new count: 2
 timer_add, @ 0x00000590 ; timer is unlinked  ; added timer to tail ; new count: 3
 usb device connection: 00000A9C , 1
 usb enumerated: 00000A9C , 00000002
interrupt on PB08-PB15.
 usb device c�

m64 plugged in after turning on:

 mode change (ignore)
 finished monome class init

// wh
 usb vbus change, new status: 1
 ******************* usb vbus errorite whale //////////////////////////////// 31884 3976 8
 read preset 0
 timer_add, @ 0x00000618 ; timer is unlinked  ; list was empty  ; added timer as sole element  ; added timer to tail ; new count: 1
 timer_add, @ 0x000005BC ; timer is unlinked  ; added timer to tail ; new count: 2
 timer_add, @ 0x00000590 ; timer is unlinked  ; added timer to tail ; new count: 3
 usb device connection: 00000A9C , 1
 usb enumerated: 00000A9C , 00000002

Still working on understanding how all of the connect code works, will try and update later this week once I’ve made some headway. I figure since we’re getting to usb enumerated it’s at least recognizing it’s connected, just need to determine why it isn’t registering that it’s actually a monome.

Eurorack firmware modding