Shop OBEX P1 Docs P2 Docs Learn Events
Microcontroller Design Debugging (strange code behaviour) — Parallax Forums

Microcontroller Design Debugging (strange code behaviour)

FlyingFishFingerFlyingFishFinger Posts: 461
edited 2010-04-06 02:32 in General Discussion
Hi folks-
This isn't quite Parallax related, but since it's not a direct question about the micro I'm using I thought it's fair game.
I designed a microcontroller board with an ATMega, CAN chips, Vregs and an FTDI chip, about the size of a Stamp. When I assembled it, it worked for about 10 seconds ("USB device found" etc) then it disconnected and released magic smoke. Turns out I'd connected powerline caps backward which blew up and seem to have taken the FTDI with it for some reason.
AVRStudio was still able to correctly detect the ATMega and load code via the ICSP header. So seems like the micro is still alive, but it doesn't work right: We can set the state of any pin correctly, but that's about it. As soon as we put in loops or conditionals, it does weird stuff. For example:
If we have a loop with multiple pin toggles and a delay in it, the connected LED always immediately shows the last state in the loop ( if the last state was on) or is partially on ( if the last state was off).
If we have a conditional (we tried a parity check that lit either a red or greed LED) it would always immediately turn both on.
The reason I'm asking this question is, if we are able to correctly detect and program it, could the chip still be fried? Should I try rebuilding it or look for a design flaw?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
UC Berkeley '12 EECS
CalSol: UC Berkeley Solar Car
http://calsol.berkeley.edu
KJ6AWU

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2010-04-05 17:28
    You asked about a design flaw, but I thought what caused the possible damage was the caps being in backward?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage

    Parallax Engineering
    ·
  • FranklinFranklin Posts: 4,747
    edited 2010-04-05 17:31
    If you have another chip I'd set it up on a breadboard and test your code using a properly regulated power supply. Also make sure your fuses are set correctly and the clock is what you expect it to be.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - Stephen
  • FlyingFishFingerFlyingFishFinger Posts: 461
    edited 2010-04-05 17:34
    Well, since those were powerline caps I removed them for now. I guess yes, that was a design flaw because my silkscreen was backwards, but my question is more at, since we can still detect and program the chip, does this indicate
    a) A partially fried chip
    b) Another design flaw
    c) A software problem
    d) There is not enough information to tell
    ?
    We can't quite figure it out either way...

    Franklin-
    Supposedly the thing is running at 20Mhz. All I have here is a Parallax USB scope, what would be the best way to verify the clock with that?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    UC Berkeley '12 EECS
    CalSol: UC Berkeley Solar Car
    http://calsol.berkeley.edu
    KJ6AWU

    Post Edited (FlyingFishFinger) : 4/5/2010 5:39:44 PM GMT
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-04-05 17:50
    Did you replace the filter caps? If not, you could be getting brief Vdd dips that trigger sporadic brownout resets. Why not replace the caps using the correct orientation?

    -Phil
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2010-04-05 18:13
    Also, whenever I am faced with something like this with a lot of unknowns, I always start fresh. I would replace everything that could posibly have been damaged just to remove that as a possibility.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage

    Parallax Engineering
    ·
  • FlyingFishFingerFlyingFishFinger Posts: 461
    edited 2010-04-05 18:19
    Probably a good idea. This is 40+ smd components, half of them hand-soldered though [noparse]:([/noparse] [noparse]:([/noparse] I'll try that next weekend.
    I checked the frequency; the Parallax scope tells me that if I use 128Khz internal oscillator it works fine, but it's too slow to verify my external crystal...
    And apparently 128Khz is too slow to program it besides setting the fuses...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    UC Berkeley '12 EECS
    CalSol: UC Berkeley Solar Car
    http://calsol.berkeley.edu
    KJ6AWU
  • kwinnkwinn Posts: 8,697
    edited 2010-04-05 18:46
    Take the advice Chris posted and start fresh. I have seen chips that were only partially damaged. They would work for most functions but consistently fail on others, or the memory would hold data fine in most locations but not in a few other areas.

    My approach to boards that may have been damaged by spikes, surges, or failed regulators has always been to replace all the active components, or at least as many as practical. Better to replace $100.00 in chips than spend $1,000.00 for travel to come back later.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2010-04-06 02:32
    It sounds like it never really "worked" at all because you had not had a program running before the smoke. Now the smoke could be a "smoke screen", that is you are not seeing the real fault which could have existed along with the back-to-front cap. From the sound of it it is as if the regulator is not supplying enough current so that when the CPU ramps up current consumption it crashes. Check the regulator voltage and another thing, if your decoupling is insufficient around the CPU it will crash.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
Sign In or Register to comment.