Compiling and bootloading issues

I'm trying to hack on the WTPA code to add some MIDI functions and I am having problems getting a usable boot image. Compiling the stock code from github using the toolkit versions listed in WTPA.c and converting it with wtpaAudioBootImagePacker yields a 5.7MB AIFF file (vs. the 6.6MB 0x13 file provided). Loading this works fine up until rebooting where it boots and only the power LED lights up with no functionality or audio.

Second, smaller issue: The reboot doesn't actually happen most of the time, even when loading the stock wtpa2AudioBootFile_0x13.aiff. Waited several minutes after the audio played with all the LEDs lit up with no reboot. Then I rebooted it myself and everything is working fine with the stock firmware (phew, I was scared I bricked it with my shitty file).

Any ideas why my wtpaBootImage is sucking? I'm on OSX. All of it compiles without any warnings or errors (the main app at least, I did have to add a couple return(0)s to wtpaAudioBootImagePacker.c). I can try getting a Linux VM together when I have some more time and see if that helps any.

Here's the output from the audio packer:
Packing ../../../WTPA2.tmb/application/wtpaBootImage into a WTPA2 audio bootloader file...
Boot file length in bytes = 21358
CRC = 0x354E
Boot file successfully created!
«1

Comments

  • edited January 2015
    Here's the output from make in case that helps anything:

    $ make all
    avr-gcc (GCC) 4.7.2
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


    Compiling: WTPA.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=WTPA.lst  -std=gnu99 -MD -MP -MF .dep/WTPA.o.d WTPA.c -o WTPA.o

    Compiling: globals.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=globals.lst  -std=gnu99 -MD -MP -MF .dep/globals.o.d globals.c -o globals.o

    Compiling: eeprom.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=eeprom.lst  -std=gnu99 -MD -MP -MF .dep/eeprom.o.d eeprom.c -o eeprom.o

    Compiling: uart.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=uart.lst  -std=gnu99 -MD -MP -MF .dep/uart.o.d uart.c -o uart.o

    Compiling: softclock.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=softclock.lst  -std=gnu99 -MD -MP -MF .dep/softclock.o.d softclock.c -o softclock.o

    Compiling: midi.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=midi.lst  -std=gnu99 -MD -MP -MF .dep/midi.o.d midi.c -o midi.o

    Compiling: microSD.c
    avr-gcc -c -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=microSD.lst  -std=gnu99 -MD -MP -MF .dep/microSD.o.d microSD.c -o microSD.o

    Linking: WTPA.elf
    avr-gcc -mmcu=atmega644p -I. -gdwarf-2   -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=WTPA.o  -std=gnu99 -MD -MP -MF .dep/WTPA.elf.d WTPA.o globals.o eeprom.o uart.o softclock.o midi.o microSD.o --output WTPA.elf -Wl,-Map=WTPA.map,--cref    -lm

    Creating load file for Flash: WTPA.hex
    avr-objcopy -O ihex -R .eeprom WTPA.elf WTPA.hex

    Creating load file for Flash: WTPA.bin
    avr-objcopy -O binary -R .eeprom WTPA.elf WTPA.bin

    Creating load file for EEPROM: WTPA.eep
    avr-objcopy -j .eeprom --set-section-flags .eeprom=alloc,load \
        --change-section-lma .eeprom=0 -O ihex WTPA.elf WTPA.eep
    avr-objcopy: --change-section-lma .eeprom=0x0000000000000000 never used

    Creating Extended Listing: WTPA.lss
    avr-objdump -h -S WTPA.elf > WTPA.lss

    Creating Symbol Table: WTPA.sym
    avr-nm -n WTPA.elf > WTPA.sym


  • Are you making your bootloader AIFF from the .bin output from your compile?

    And also I believe "wtpaBootImage" is not what you want to pack. It might be an SD card boot image. Pack the bin. Or download the aiff I have up on the site.

    Let me know how it goes and good luck!

    Ps: good for you for working on the code.
  • Ah, there ya go. I was loading the wrong file. The bin loads fine and it rebooted properly. Thanks, Todd!

    This thing just got a whole bunch cooler now that I can hack on it! I'll have some pull requests for ya at some point.
  • Awesome. Keep up the good work.
  • Hello. I am a n00b who has learned to run before he could crawl and now my nose is all rugburned. I have managed to successfully compile a hex (which is ok because I can always avrdude -V -p m644 -c USBasp -P usb -U flash:w:WTPA.hex)  but I'm stumped on how to make the aiff. And just some fair warning, my next question will be how to pass all MIDI IN thru the MIDI OUT. Poor WTPA2 is sick of having to watch all the fun and jack off in the corner.

    image
  • well MIDI out and THRU are somewhat different, hardware may be better approach, here's one idea for a small daughter board that takes a 6n138 output image


  • Oh I know the difference. Software pass thru would work just fine for me. My Shruthi-1 and Anushri from Mutable Instruments both do it just fine and actually, I used to have a custom WTPA2 DPCM firmware that did it!
  • Something like this: cd ~/src/WTPA2/application && make clean && make all && cd ~/src/WTPA2/tools/audioBootPacker && ./wtpaAudioBootImagePacker ../../application/WTPA.bin

    That'll leave you with tools/audioBootPacker/wtpaAudioBootFile.aiff
  • edited March 2015
    Thanks for the help, scragz but did I mention I'm using windoze? Also, I'm a n00b? 
  • On windows you may need to get into Cygwin, a sort of "gateway drug to linux". There's also an AVR tool chain called WINAVR which I think is pretty good. Start by looking at those.
  • Sorry, I wasn't paying enough attention. If the boot packer is what you are trying to use then just go to whatever shell you run avr dude from, navigate to the "tools" then "audioBootPacker" directory in the WTPA2 directory and try to run the audio boot packer program. You may need (probably will need) to recompile it for Windows. If so, see Cygwin above. But it's not hare once you get the hang of it.
  • OK, it's really hard to concentrate over the sound of all this breathing I'm doing from my mouth, but I think I understand what you're saying. I've got the shell stuff with WINAVR already all setup from compiling Mutable firmwares. I just don't know enough about syntax to get the commands right and where to run what from where. I'm clearly over my head and wasting your time.  Sorry, dudes.
  • So you know how to navigate to a location using the shell, right? Use "cd" to get to "tools/audioBootPacker". Then type "./audioBootPacker" to try and run it. Let us know what it says.
  • C:\Narrat1ve\WTPA2>sh
    sh-2.04$ cd tools/audiobootpacker
    sh-2.04$ ./audioBootPacker
    sh: ./audioBootPacker: No such file or directory
    sh-2.04$

     
  • unix is case sensitive, tools/audioBootPacker not  tools/audiobootpacker
  • No, I think it was OK with all lowercase because it would have yelled at me with a "No such.." right?

    But I tried, just to be sure. Same results:

    C:\Narrat1ve\WTPA2>sh
    sh-2.04$ cd tools/audioBootPacker
    sh-2.04$ ./audioBootPacker
    sh: ./audioBootPacker: No such file or directory
    sh-2.04$ 
  • This may or may not be progress:

    C:\Narrat1ve\WTPA2>sh
    sh-2.04$ cd tools/audioBootPacker
    sh-2.04$ make
    cc wtpaAudioBootImagePacker.c -o wtpaAudioBootImagePacker
    process_begin: CreateProcess(NULL, cc wtpaAudioBootImagePacker.c -o wtpaAudioBoo
    tImagePacker, ...) failed.
    make (e=2): The system cannot find the file specified.
    makefile:11: recipe for target 'wtpaAudioBootImagePacker' failed
    make: *** [wtpaAudioBootImagePacker] Error 2
    sh-2.04$ 
  • It's not real specific about what it can't find, but you should list that directory.
    Make sure wtpaAudioBootImagePacker.c is in that directory.

    Try running just "cc" on the command line.  If it runs but complains that it has no input files, then windows can find your compiler.

    The problem is most likely that the compiler can't find the C target file because windows has some fucked up idea about paths.

    You may have to call the compiler using the absolute path to that c file.  It would look something like:

    cc C:\My\Path\To\WTPA2\tools\wtpaAudioBootImagePacker.c

    tack a "-o wtpaAudioBootImagePacker" or "-o HELLYES" on the end if you want to output file to be called something other than a.out.

    The google terms that will help you here are "path" and "Makefile" and maybe "windows CC compiler"
     
  • Also, dunno if your shell can do "pwd" but try that.  It may illuminate your path problems.

  • Tried cc. "Command not found." 

    Let's back up a second. You guys saw the part where I was able to "make all" from the command line (not shell) and actually got the .hex and .bin files to compile, right? I feel like if that's working, the issue here is that my command line syntax for the audioBootPacker is just wrong somehow...


  • Oh and pwd in the shell showed the correct path.
  • Not sure what the difference in Windows is between a shell and a command line, so I can't help you there.  "Shell" and "Terminal" and "Command Line" all mean similar things in Linux.

    Do this:
    List the contents of the directory.  On my machine that is "ls" (for "list").
    Is the executable program in there?  If so, execute it with "./nameOfExecutable".  If you give it the wrong command line options it will still run, it will just spit out usage instructions and do nothing.
    If it's compiled incorrectly for your machine, you will probably get some exciting fault message.

    If you get can't find, it isn't one of those problems.  In general, "can't find" is not a syntax problem, it means you used the wrong name or the wrong path, or occasionally a permission problem.

    I just checked and the name of the executable file is not "audioBootPacker" on my machine, so that's definitely part of the problem.


  • Is the executable "Makefile" or "wtpaAudioBootImagePacker.c"? You're really outing me an an ignoramus here, Todd!



  • I think i see the issue, bleo is under the impression that you build the audiobootpacker like a hex file but if I understand correctly, it's just a program to generate the audio file correct?  In that case, he'll need a different set of tools to compile that program for windows no?
  • Ohhh yeah this isn't really *compiling*, is it? Good call, Raph!
  • I hate to say it but this might be a good time to build a linux box.  There will be a head size indentation in the wall next to the monitor for a bit but in the long run, its worth it and it's actually less frustrating than trying to get some of this stuff up and running on a windows box.  I use an old Thinkpad and run Xubuntu and have all the toolchains/compilers set up there.
  • edited March 2015
    "Is the executable "Makefile" or "wtpaAudioBootImagePacker.c"?"

    Runnning `make` will use the Makefile to turn the C code in wtpaAudioBootImagePacker.c INTO an executable named wtpaAudioBootImagePacker.

    "make (e=2): The system cannot find the file specified."
    "Tried cc. "Command not found." "

    This is your problem. You need a C compiler in your path.
  • Makes sense. Do I define the path on the command line or somewhere else? If on the command line, could you give me an example of the syntax? 

    And of course, I plan on making a super-clear how-to when this is all said and done!

    And then start whining about soft midi thru. Well, *continue* whining about it. :P
  • Do you use WTPA2's MIDI out at all? Does anyone? If you don't, soft MIDI through is pretty simple to program.
  • I don't and probably never would. I can't really think of one situation where it would be really useful to get MIDI messages of the WTPA2 button presses. I guess, like the manual suggests, if you wanted to record a caveman mode performance on the WTPA2, the current MIDI out functionality would be a must. But why give a caveman such high tech love?

    I'm pretty sure being the wizard you are, Todd, you could pretty easily also come up with a boot toggle to switch twixt out, soft thru or a merge of MIDI IN and caveman generated events.

    But I'd be totally fine with soft thru only. I think it took Andy like 5 minutes to add it to his DPCM firmware for me. 
Sign In or Register to comment.