Apologies for spam; we've changed our policy by requiring approval for accounts, and deleted all existing spam and user - thanks for your help flagging content. We continue to test our forums and Vanilla software, aiming for release early in 2013. If you need to give us feedback outside the forum, contact us via http://createdigitalmusic.com/contact/ or on Facebook
I think I broke it... issues with firmware upload on meeblip micro
  • jamescjamesc

    Hi all,

    I was planning to mod some of the easier parts of the firmware (switch allocation etc)... when I flashed the new .hex via a USBtinyISP v3.0 it appeared to go well however I noticed the file size of the .hex was massive so I figured I messed up something with the compiling (using Amtel Studio).

    As the meeblip wasn't working I decided to flash the original .hex (sourced from github) until I could figure out what I did wrong...

    when I flashed the original .hex the file sizes were similarly large and took a lot longer to flash than the example shows. Whilst the meeblip powers up, it doesn't appear to be receiving midi or anything....

    what have I done wrong? I have copied the terminal output etc

    Thanks for your help again!

    ////////////////////////////////////////////////////////////

    192-168-1-9:~ james$ cd /Users/james/GitHub/meeblip-synth

    192-168-1-9:meeblip-synth james$ ls make-micro.bat make-se.bat meeblip-micro.hex meeblip-se-v2.hex meeblip-se.hex meeblip1hardware.eep make-se-v2.bat meeblip-micro.asm meeblip-se-v2.asm meeblip-se.asm meeblip.eep readme.txt

    192-168-1-9:meeblip-synth james$ avrdude -c usbtiny -p m32

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.01s

    avrdude: Device signature = 0x1e9502

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.

    192-168-1-9:meeblip-synth james$ avrdude -c usbtiny -p m32 -U flash:w:meeblip-micro.hex

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.01s

    avrdude: Device signature = 0x1e9502 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "meeblip-micro.hex" avrdude: input file meeblip-micro.hex auto detected as Intel Hex avrdude: writing flash (14674 bytes):

    Writing | ################################################## | 100% 24.96s

    avrdude: 14674 bytes of flash written avrdude: verifying flash memory against meeblip-micro.hex: avrdude: load data flash data from input file meeblip-micro.hex: avrdude: input file meeblip-micro.hex auto detected as Intel Hex avrdude: input file meeblip-micro.hex contains 14674 bytes avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 20.03s

    avrdude: verifying ... avrdude: 14674 bytes of flash verified

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.

  • jamescjamesc

    i tried using

    avrdude -c usbtiny -p m32 -B 1 -U flash:w:meeblip-micro.hex -U lfuse:w:0xBF:m -U hfuse:w:0xD9:m -U eeprom:w:meeblip.eep

    receiving error

    avrdude: input file meeblip.eep auto detected as Intel Hex avrdude: ERROR: checksum mismatch at line 4 of "meeblip.eep" avrdude: checksum=0xa1, computed checksum=0xa0 avrdude: read from file 'meeblip.eep' failed

    using eeprom:w:meeblip1hardware.eep instead i get no errors/runs through normally but again large file size etc etc

  • jamescjamesc

    I just tried on a PC and get the same thing...

    C:\Users\Cassie\meeblip-synth>make-micro.bat

    C:\Users\Cassie\meeblip-synth>avrdude -c usbtiny -p m32 -B 1 -U flash:w:meeblip- micro.hex -U lfuse:w:0xBF:m -U hfuse:w:0xD9:m -U eeprom:w:meeblip.eep

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.12s

    avrdude: Device signature = 0x1e9502 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

    avrdude: erasing chip avrdude: reading input file "meeblip-micro.hex" avrdude: input file meeblip-micro.hex auto detected as Intel Hex avrdude: writing flash (14674 bytes):

    Writing | ################################################## | 100% 3.91s

    avrdude: 14674 bytes of flash written avrdude: verifying flash memory against meeblip-micro.hex: avrdude: load data flash data from input file meeblip-micro.hex: avrdude: input file meeblip-micro.hex auto detected as Intel Hex avrdude: input file meeblip-micro.hex contains 14674 bytes avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 2.97s

    avrdude: verifying ... avrdude: 14674 bytes of flash verified avrdude: reading input file "0xBF" avrdude: writing lfuse (1 bytes):

    Writing | ################################################## | 100% 0.01s

    avrdude: 1 bytes of lfuse written avrdude: verifying lfuse memory against 0xBF: avrdude: load data lfuse data from input file 0xBF: avrdude: input file 0xBF contains 1 bytes avrdude: reading on-chip lfuse data:

    Reading | ################################################## | 100% 0.01s

    avrdude: verifying ... avrdude: 1 bytes of lfuse verified avrdude: reading input file "0xD9" avrdude: writing hfuse (1 bytes):

    Writing | ################################################## | 100% 0.01s

    avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xD9: avrdude: load data hfuse data from input file 0xD9: avrdude: input file 0xD9 contains 1 bytes avrdude: reading on-chip hfuse data:

    Reading | ################################################## | 100% 0.01s

    avrdude: verifying ... avrdude: 1 bytes of hfuse verified avrdude: reading input file "meeblip.eep" avrdude: input file meeblip.eep auto detected as Intel Hex avrdude: ERROR: checksum mismatch at line 4 of "meeblip.eep" avrdude: checksum=0xa1, computed checksum=0xa0 avrdude: write to file 'meeblip.eep' failed

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.

    C:\Users\Cassie\meeblip-synth>avrdude -c usbtiny -p m32 -U flash:w:meeblip-micro .hex

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.03s

    avrdude: Device signature = 0x1e9502 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

    avrdude: erasing chip avrdude: reading input file "meeblip-micro.hex" avrdude: input file meeblip-micro.hex auto detected as Intel Hex avrdude: writing flash (14674 bytes):

    Writing | ################################################## | 100% 9.44s

    avrdude: 14674 bytes of flash written avrdude: verifying flash memory against meeblip-micro.hex: avrdude: load data flash data from input file meeblip-micro.hex: avrdude: input file meeblip-micro.hex auto detected as Intel Hex avrdude: input file meeblip-micro.hex contains 14674 bytes avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 8.44s

    avrdude: verifying ... avrdude: 14674 bytes of flash verified

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.

  • meeblipmeeblip
    Accepted Answer

    Hey James - From your logs, I suspect the problem is a corrupted eeprom setup file. Since the MIDI channel and power-up patch are stored in eeprom, if it doesn't get loaded correctly you end up with unpredictable behaviour. Email me and I'll send you a fresh copy of the eeprom file.

  • jamescjamesc

    it worked! thanks again - very helpful

    would it be difficult for me to create my own eeprom file - if I edit the start up patch so LFO is enabled then I have a free switch for something else and can just turn the LFO by turning the depth to 0...

  • meeblipmeeblip
    Accepted Answer

    You can edit the file in a hex editor. The MIDI channel (channel 1) is stored in the last byte, the current patch is stored in the second last byte. For Micro, the default patch is the first one, stored in the first 16 bytes of eeprom. See the section "MIDI Control Change parameter table" in the code for the order of the parameters. The 16 switches are packed into the last two bytes of the 16 byte patch - just flip the appropriate bits to turn them on/off at startup.

    To generate the eeprom file for the Micro, I just edited the patch on a MeeBlip SE and dumped the contents of the eeprom memory to a file. As a result, there might be a handful of extra patches (each offset by 16 bytes).

  • jamescjamesc

    hello, I have been experimenting with the .eep file in hexedit for a while to no avail....

    I was just wondering if midi channel 1 would be denoted by one (cause it seems to be denoted by 0A / 10)... is this some sort of bit shift thing or am I looking at it wrong?

  • meeblipmeeblip

    The file format on disk is different than the raw format. 0A / 10 looks like a line break.

  • phroggieyphroggiey

    Hi, I'm having exactly the same two problems mentioned here. I had a meeblip micro working for a year or so, but I just flashed the .hex and .eep files from github (as above). I had the same issue with avrdude auto-detect thinking the .eep file was in Hex format, so I used -U eeprom:w:meeblip.eep:r to assign it as binary. But again, no sound at all. The LED's not even flashing when I send MIDI notes. I can't get it to make any sound.

    The other issue is assigning MIDI channel numbers in the EEPROM. I'm not familiar with programming them and cannot (as I suppose jamesc is above) find where the MIDI channel data reside in the file. I'm guessing it's somewhere in this bit!! "3A 32 30 30 33 45 30 30 30 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 30 30 30 31 31 41 0A", before 3A 30 30 30 30 30 30 30 31 46 46 0A. Is that right?

    Thanks a lot in advance.

  • phroggieyphroggiey

    Just realised it shouldn't be binary...

Add a Comment