I've had an Atmega168 SD card data logging circuit working great on breadboard. It samples 2 digital and 3 analogue inputs and dumps them as a time stamped records in a .csv file, so the SD card can be removed and read directly by a spreadsheet package. Well, I then transfered it all to strip board, and it's as dead as a dodo. To diagnose the fault, I only have a 4MHz digital scope, but the circuit runs off a 8MHz external crystal. The circuit runs off a 9V battery, but into a 3.3V regulator. I put a 33Ohm resistor between battery and regulator to measure current draw. I get a strange result:

• An oscillating waveform (square wave ish) with a fundimental period of around 8uS (64 clock cycles?).
• The volt drop across the resistor is around 2.2V every 8uS for around 1uS. This would mean around 60mA across it, which sounds very high. This is the max current an IO pin could source? The worst an IO pin could be experiencing in the circuit is an LED with a 300 Ohm resistor in series, but at startup (i.e. nerdkits bootloader enabled) nothing should be set as an output.

My question is, the first step is the check the crystal oscillator is functioning. What is the easiest way to do this (without a higher frequency scope)?

The evidence above would tend to lead me to believe it is functioning, with the MCU caught in some sort of startup cycle, then browning out?

My next question would be, what would be the next thing to check?

Any input much appreciated.

If you haven't already, try placing a capacitor from each leg of the crystal to ground. 18 to 22pf usually work.

Rick

If you haven't already, try placing a capacitor from each leg of the crystal to ground. 18 to 22pf usually work.

Rick

As you suspect the crystal remove it just to see what happens. Or replace with a new one (probable the better test). Make sure you have a fresh battery.

Please post your working code somewhere you can use http://nerdkits.pastebins.com if you need a site.

Ralph

Whoops sorry for the double post... using my phone

Hi Mujda,

Do you have the ability on your board to reprogram the chip? If so my suggestion is to try and load a simple program onto the MCU, perhaps something that blinks an LED or sends some data out the serial port. That will at least let you know if your chip is running on your board or not, and perhaps help you debug whether the problem is the chip or a problem on your board.

Humberto

Thanks folks for your helpful feedback.

I'm feeling a little rediculous. The strange scope readings I was getting were actually a result of the voltage regulator doing something clever (it turns out it seems to not be a simple linear one - it must be using some switching mechanism) in combination with the resistor I put in-line with it.

After doing what you suggested, I took several steps back, and realised I was getting the 8uS pulses without any MCU. I took out the in-line resistor (which removed the ripple), then found the MCU clock was completely dead.

So, I took a careful look at the crystal oscillator, and eventually found one side of the crystal was shorting to earth.

The good news is it's now functioning perfectly - recording log files directly onto the SD Card.

Thanks also for pointing out the paste bin. I've not used one before, but it's a nice method for distributing code. I commit to try and upload the code I have working by the end of the week. The main issue with it is you can't yet adjust the real time clock, it simply resets to zero every time power it up. I've put in the LED's and switches to do this, but the code currently ignores them. It's quite tricky thinking up a system to set the clock with 2 LED's and 2 switches that's simple to use.

The other hardware issue is that the ADC needs a good external voltage reference, right now it references from Vcc.

Thanks,

Mujda

As promised, here's by working code for the data logger. It's designed to function @ 8MHz and 3.3V and upload with the Nerkits USB cable.

You'll need to change the Nerdkits bootloader code to work at 8MHz, then upload it with a 'Direct Access Parallel AVR' cable, otherwise known as a chopped up printer cable. After that, the following should work:

The directory you compile in needs an empty 'dep' directory Compile and upload with:

Make
Make -f Makefile.upload

Makefile

Makefile.upload

FAT32.c

FAT32.h

SPI_Routines.c

SPI_Routines.h

SD_Routines.c

SD_Routines.h

UART_Routines.c

UART_Routines.h

SD_main.c

Hope this manages to help someone.