›

Running into trouble on build.

vergessenvergessen
edited August 2014 in Troubleshooting
Hey all,

As the title says, I'm running into trouble on my build here.  The board is completely put together, all ICs seated properly, etc, and yet, powering it on will produce intermittent results.  Those tend to be:  light every LED and keep them lit for some period of time in the rage of 30+ seconds and then light only one odd LED afterwards, light no LED whatsoever, or light a subset of LEDs.  Futherrmore, there's no activity at all on the OLED.

What I've done so far:

Flash AVR with bootloader hex file.
Build .BIN file and copied that to SD card.

Reflow solder around IC1 socket.
Take out each IC, verify correctness and orientation and reseat.
Verify orientation of each resistor network.
Verify correct voltage (4.9ish) and no continuity between +5VDC and ground at AVR ISP test point.

I'm at a loss at this point.. Anyone have any suggestions or ideas?  I can post pictures if necessary.

Thanks in advance

Comments

  • cj55cj55
    edited August 2014
    You have to flash the firmware (.BIN File on the SD card) by pressing down the encoder while powering on.
  • vergessenvergessen
    Hm, I might have done that earlier, possibly.  Either way I'm still not getting anything on the OLED.  Surely even without the firmware bin file the OLED would display something, even if it were non ASCII junk, no?

    Is there a way to reset the firmware?  Of should it be re-written (even after a bad or interrupted write) anytime I hold the encoder down while powering on?
  • cj55cj55
    Did you get the ATmega644 from the kit or from the Sonic Potions shop, or is it self sourced?
    If it is self sourced, are you shure you have flashed the bootloader on the AVR properly?
    Normally when powering on while holding the encoder down, these messages from the bootloader are shown on the OLED:
    - "Bootloader v1.2"
    - "SD Card OK"
    - "updating... (1/2)"
    - "updating... (2/2)"
    - "success! please reboot..."
    And during the update process the step LEDs are showing the progress.
  • vergessenvergessen
    edited August 2014
    * Edited to remove extraneous whitespace.

    The OLED is completely dead, not even so much as a blip during power on.  Also, I'm still seeing issues where all the LEDs might be lit, none may be lit, or some may be lit.  For each case, I definitely have 4.9V at the TP to the right of IC1.

    As far as the AVR is concerned, it's self sourced (using the Mouser PN) and was flashed using avrdude (via crosspack for mac), the Adafruit pocket programmer, and a breadboard:






    gobinau$ avrdude -p atmega644 -c usbtiny -U flash:w:Downloads/SD_Card.hex

    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.00s

    avrdude: Device signature = 0x1e9609

    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 "Downloads/SD_Card.hex"

    avrdude: input file Downloads/SD_Card.hex auto detected as Intel Hex

    avrdude: writing flash (65146 bytes):

    Writing | ################################################## | 100% 0.00s

    avrdude: 65146 bytes of flash written

    avrdude: verifying flash memory against Downloads/SD_Card.hex:

    avrdude: load data flash data from input file Downloads/SD_Card.hex:

    avrdude: input file Downloads/SD_Card.hex auto detected as Intel Hex

    avrdude: input file Downloads/SD_Card.hex contains 65146 bytes

    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 0.00s

    avrdude: verifying ...

    avrdude: 65146 bytes of flash verified

    avrdude: safemode: Fuses OK (H:FF, E:99, L:62)

    avrdude done.  Thank you.

  • vergessenvergessen
    Hm... a thought.  IF the AVR went bad (say it was zapped by ESD), is it still possible to flash it or would avrdude return an error?  Also, from what I'm reading here in the forums, the atmel is pretty much the controller for the entire front board, including the display.  If it were bad, would the OLED light at all, or is it feasible that it would mimic what I'm seeing here?

    I'm not certain about what the cause is behind the LED and powering on other than maybe one of the ICs is also bad, or close to failure if that's possible.  

    Again, I can post pictures if need be; I also have a good meter and an o-scope (albeit an older Tek that only goes to 100Mhz  IIRC it's a 466).  Note that my o-scope skills are quite rusty as it's usually not used much here, so I might need some extra instruction there. 
  • julianjulian
    i have to think about it a little bit.
    first of all.

    you only flash the bootloader to the avr.
    this will not activate any LEDs or the display.
    it is possible that the leds light up, but this is random due to the state of the shift registers.

    when you hold down the encoder while powering up the device you should see the bootloader message on the OLED.

    this should even work without the attached mainboard, since it all uses only the avr.
    your encoder is soldered correct, too? otherwise you can't start the bootloader.

    you also have to set some of the fuse bits. I use the following avrdude commands:

    # set fuses
    avrdude   -B100 -c usbasp -p m644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m
    # flash bootloader
    avrdude  -B1  -c usbasp -p m644 -U flash:w:SD_Card.hex:i
    # lock bootloader - BLB1 Mode 2 = SPM is not allowed to write to the Boot Loader Section
    avrdude  -B1  -c usbasp -p m644 -U lock:w:0x2F:m

  • vergessenvergessen
    edited August 2014
    Hi Julian, guten abend :)

    I didn't realize the bit about the fuse bits when flashing the AVR.  I will give that a try this evening when I return home and have a bit of free time.

    The LEDs lighting (full, partially or none) is consistent every time.  When they are all fully lit (or even partially), they remain lit for close to a minute (maybe?) and then all shut off except two odd ones... namely not those that the build instructions mention in the first test post-flashing.  Button presses do not activate or disable LEDs either, although I suspect that functionality would come from the AVR.

    As far as the rotary encoder goes, yes, it is soldered correctly, although the center pin (common I believe?) was pushed up a little bit by my own stupid mistake, but does not appear to be broken.  I might pick up a spare tonight on the way home.  I need to get a spare 47nF cap anyway.  When I was testing mine here with the LCR I broke the lead and the best I had as a replacement was an orange drop.  Note that the reported issues were occurring _before_ the orange drop was used.  ;)
  • julianjulian
    edited August 2014
    47nf is not critical at all.
    could as well be left off ;)

    the thing about the fuses is that it sets the clock source to external.
    otherwise the AVR will only run at 1MHz with the internal clock instead of the 20MHz external quarz.
  • vergessenvergessen
    edited August 2014
    Hmm.... so I ran the first command you gave to set the fuses which appeared to work just fine.  However, trying to write the bootloader next fails every time:

    avrdude -B1 -c usbtiny -p m644 -U flash:w:SD_Card.hex:i

    avrdude: initialization failed, rc=-1

             Double check connections and try again, or use -F to override

             this check.

    avrdude done.  Thank you.


    Ugh... it appears that after running that first command I can't flash the chip at all anymore, even with the force flag set:

    avrdude -B1 -c usbtiny -p m644 -U flash:w:SD_Card.hex:i -F


    avrdude: initialization failed, rc=-1

    avrdude: AVR device initialized and ready to accept instructions

    avrdude: Device signature = 0x000000 (retrying)

    avrdude: Device signature = 0x000000 (retrying)

    avrdude: Device signature = 0x000000

    avrdude: Yikes!  Invalid device signature.

    avrdude: Expected signature for ATmega644 is 1E 96 09

    avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

             To disable this feature, specify the -D option.





















    avrdude done.  Thank you.


  • vergessenvergessen
    edited August 2014
    On a good note though, IT'S ALIVE!!!!  The bootloader came up and I was able to load the .bin just fine.  The only part that appears to be missing is the ability to lock the bootloader at this point.  Is there any chance you can point me to a good reference on what the fuse command did?

    I have yet to really fiddle with things yet, but I should have more as the week progresses.  I am also planning on adding a small headphone amp mounted under the displayboard; it will be based off a TDA2822 and will feed directly from the power jack taps before it goes to the 7805.

    The project is described in detail at http://www.paulinthelab.com/2013/12/mp3-headphone-amplifier-tda2822m.html
  • julianjulian
    you can check the fuse settings here
    http://www.engbedded.com/fusecalc
    just enter the hig,low and extended hex values at the bottom of the page.

    in short:
    - disable clock div 8
    - change internal clock to external quarz
    - enable brown out detection 4.3v
    - enable bootloader section in flash


    I don't know the usb tiny.
    but can you set the speed of the tiny somewhere.
    with old avr dude versions you have to set a slow/fast jumper depending on the clock settings of the avr.
    but normaly this is only neccessary for the initital fuses, when the avr is too slow for fast programming due to the internal clock. does it work with -b100 instead of b1? (this sets the programming speed)
  • vergessenvergessen
    Thanks Julian, it looks like I have a bit more reading to do since I had another project in mind with microcontrollers anyway.  I will check modifying the parameter for the -b switch later this evening when I get home from work again.  I'm just excited that it's up and running at this point and there weren't any show stopping mistakes on my part (assembly wise).
  • julianjulian
    another idea.
    try removing the SD card while prgramming.
    My USBasp has no problems with it, but I don't know the tiny.
    the SD card shares the SPI pins with the ISP.
  • vergessenvergessen
    edited August 2014
    Hm... did I miss a spot in the build?  I mean, do we have a SPI header on the board?  I only ask as I've been removing the atmel from the circuit and programming it on a breadboard with the ISP.  That being said, I suspect the issue is because I'm doing just that and I do _not_ have an external clock on the breadboard, once the fuses are set the chip refuses to be programmed because it's not getting a clock signal.

    My local store was out of 20MHz crystals but I did get my hands on a resonator, so that _should_ do the trick in a pinch.  I'll try to give that a whirl tonight and report back.

  • cj55cj55
    edited August 2014
    Yes, there is a standard 6 pin ISP connector on the right side of the AVR. So no need to programming it on a bread board.
    You even mentioned it yourself in your first post (voltage test) :-)
  • vergessenvergessen
    Ach!!!!  Stupid me, I didn't even think of it as that, meh.  Oh well, point noted and thank you guys, it's much appreciated :D.  Will try setting the bootloader flags here in a few.


    On another note, as I mentioned earlier, I'm a bit interested in adding an amplified 3.25 stereo headphone jack to the mix.  As it stands now, I was originally thinking of making it draw from the power supply before it gets to the 7805 but I'm beginning to rethink this and think that powering it via battery might be a slightly better option.  Either way, as a potential benefit to others who want a headphone jack, in future revisions it might be worth adding a small separate header that has the audio output, so if one wants to route that to a smaller amplifier (or whatnot) it's pretty easy as an addon.  An alternative would be to include that as part of the Trigger IO board, but that's entirely up to Julian.  Just a thought :D

    Thanks for all the help again and great job on the project.  Definitely enjoying it so far.  Now to make myself a case...
Sign In or Register to comment.