Ok, I have now tracked the issue down to flashing the AVR with the muboot_0.54.hex and the shruthi1_0.91.hex together. When I turn the verify on I get this:
avrdude: verifying …
avrdude: verification error, first mismatch at byte 0x7801
0x67 != 0x40
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK
avrdude done. Thank you.
if I just flash the shruthi1_0.91.hex, everything works fine on the control board, if I flash it like shown in the instructions, it bricks it (all lights on, nothing)
(C:\\AVR>avrdude -c usbtiny -p m644p -B 1 -V -U flash:w:shruthi1_0.91.hex -U flash:w:muboot_0.54.hex)
- something I just noticed: The bootloader hex takes 38 sec to write vs the 42 sec it takes for the main app despite being 5 K (???)
You mean that when you flash the main firmware only, it works?
Maybe it’s due to a difference between the linux/OS X and windows behaviour of avrdude?
I’m very curious about the 0x7801 address. It’s far from being random - it’s the first byte of the bootloader area… when the bootloader size is set to 2kb.
Maybe there’s something wrong in the fuses and the bootloader size is set to 2048 bytes instead of 1024 bytes?
Regarding the bootloader write time it’s ok - it’s a write at the end of the flash and it’s probably verifying/reading the whole thing from the start.
Question: if you write only the bootloader, does the board displays the x-x-x-x- LED pattern when the 6th switch is pressed on startup (indicating that the board is ready for a firmware update by MIDI)?
yes, when i flash with the main firmware, it works. Just flashing the bootloader makes it completely unresponsive (all lights on, nothing does nothing)
This is the firmware from the http://mutable-instruments.net/static/firmware/ location, i dont have your toolchain up on my machine to compile it
Can you read and post here the fuses? Somehow I suspect the bootloader size is wrongly configured in the fuses - so instead of booting at the beginning of the bootloader it boots 512 bytes or 1k byte earlier in the middle of wavetable data which is surely not correct code.
high fuses show
(using avrdude -c usbtiny -p m644p -U hfuse:r:high.txt:i -U lfuse:r:low.txt:i)
Looks good. I’m really stuck on this one, sorry… You could try running it for some time without the bootloader and see if there’s anything wrong/broken.
what are the disadvantages of running without the boot loader? Is it only for midi OS updates or is there more functionality that I would loose? I’ll probably grab an avr from you when I order my ssm board. Would it be worth it to try to make the bootloader here? Seems strange that I cant get it to work with just the bootloader by itself
The bootloader is here only for MIDI update, on a “sane” chip the main code runs absolutely fine without it. BUT - I suspect that what’s preventing the bootloader code to run correctly (maybe a damaged flash sector on the MCU?) might also have an impact on other functions of the chip.
it’s not the chip, i have tried two and they behave identically.
Is there any chance of you building a hex with both the bootloader and os in one? I have a theory on whats happening…
I’ll see if there’s an easy way of merging the .hex file. Maybe what’s happening is the following: the flash gets erased between the flashing of both files, so you end up with the bootloader but not the main code.
I think it is something to do with the bootloader hex itself on my windows machine. I have seen something very similar happen with a midibox project where the hex was assembled on a Mac (it was a for a PIC16F88), no matter what I did, it would not flash the code always giving an error about a mismatch (tried multiple programmers etc). The hex file was verified as good. Other hexs’ from the SVN worked fine on other chips compiled by the same person who coded the one I was having problems with using the same toolchain. Where it really gets bizarre is that if I compiled it from the makefile on my machine, it worked. No errors. The two hex files were not the same though. Sounds crazy but someone else was having the exact same issue as me so it isnt specific to my rig.
I dont think it is the two hex files having an issue since a) I cant get the bootloader to work at all when flashed by itself (holding down the 6th button does nothing) and b) if i flash them separately with -D, i get the same error (in any order)
Ok, have winavr working and can compile the OS however cant seem to get the bootloader to build (be gentle i’m a little green in this area)
C:\\WinAVR-20100110\\bin/avr-gcc -mmcu=atmega644p -lm -Wl,–gc-sections,-
start=.text=0xfc00,–relax -o build/muboot/muboot.elf
(.init9+0x0): undefined reference to `main’
make: ***** [build/muboot/muboot.elf] Error 1
So I am missing some part of the tool chain? Or does something else have to happen to the makefile?
all builds should be done from the main directory, so you have to type:
make -f hardware/bootloader/makefile
The reason is that each “subproject” (the bootloader, the shruthi-1 firmware, the … firmware) reference common code files in hardware/hal and hardware/utils - so everything, from compilation to linking has to be done from the root.
cool thanks. This has definitely been a good learning experience.
and now for the results (drumroll):
When i MAKE the bootloader and use that along with the 1.91 OS, it works fine. I can now go into bootloader mode and have the 0x0x0x0 lights and it boots normally.
Leave it to me to find the most obscure bug in the world.
I assume the bootloader on the github is the orginal one, not the current?
hehe, That would explain it as well
Thanks for the help, now down to business (aluminum cases anyone?)
I don’t think I have touched the bootloader in the past 2 months.
Crap, the bug here is that I’m stupid. the .hex file of the bootloader that was online is that of the Shruti - yes, for the ATMega328p. Sorrysorrysorrysorry
Well at least you have now the toolchain all set up What about finding cool hacks in the code?