smeezekitty,

Yes, our posts crossed in the 'post' otherwise I would have just used your suggestion (which, if you have googled how to check fuses on avr chips, is what you should do).

**********************************
The good news is that I think the problem *IS* due to the bad GND connection. I managed to confuse myself at each stage by getting the chip to run perfectly well in every way (apart from resetting when PD2 +ve) even with the GND completely disconnected! Confusion further compounded by the fact that the position of the tilt switch is invisible so sometimes I wasn't testing the connection I thought I was!!
**********************************

Thanks to everyone who made suggestions and hopefully this thread will leave a trail of symptoms that might help someone else in the future.

Thought I was on to something. I just found that the connection from pins 3 and 5 to GND [using TQFP32] was broken. Fixed it but it doesn't seem to make any difference at all!

Well that was a steep learning curve but very short! I don't know if I'm further forward but the fuses are:
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as 1
which is the default i.e. internal osc. divide by 8, serial programming enabled, reset not disabled, NO brown-out, self-programming not enabled.

Sadly I've probably made little headway in finding why PD2 has to be attached to GND for the chip to work than when I started this thread. But, look on the bright side; I've learnt lots!

(if you have come across this while trying to find out how to read fuses from a chip the answer will be something like this:
avrdude -c stk500v1 -P com3 -b 19200 -p atmega48 -U lfuse:r:lfusefile.hex:i -v
see http://www.ladyada.net/learn/avr/avrdude.html
the -v will make useful info appear but the stuff written to lfusefile.hex is pretty cryptic. don't accidentally write something to the fuses (hfuse bit 5) that stops you from being able to program the chip.

coding badly

Is the reset issue connected with determining or setting the fuses? I presumed the reset disable was for the programmer arduino? I have been using a seeeduino v2.12 atmega168, this has a nifty switch to stop automatic resetting. The programming seems to have worked pretty trouble free (surprisingly).

The reference to 'finding no clues' was specifically how to read and set fuses on a target chip using ArduinoISP as a programmer. Of course I do have avrdude v5.10 as a result of using the arduino programmer and I can probably use that but the learning curve will be steep (and I hoped someone would just say 'press button A' or 'you should have done X' etc).

Patrick

codingbadly, smeezekitty,

yes I saw that westfw sketch but a) it's probably too big to fit onto atmega48 and only been tried on 168 and 328 b) I have no serial output.
So I thought using the arduino as isp might be better idea. Found no clues as to how to do that if I hold down shift when sending sketch I do get some lines referring to lfuse, hfuse, efuse but no values that look anything like plausible ones.

Code:

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "C:\Program Files\arduino-0022\hardware/tools/avr/etc/avrdude.conf"

         Using Port            : \\.\COM3
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv:
avrdude: Recv:
         AVR Part              : ATMEGA48
         Chip Erase delay      : 45000 us
         PAGEL                 : PD7
         BS2                   : PC2
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no        256    4      0  3600  3600 0xff 0xff
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         65     6    64    0 yes      4096   64     64  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [98]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
avrdude: Send: A [41] . [84]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [85]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [86]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [87]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [89]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: Send: A [41] . [81]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: B [42] Y [59] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [00] . [00] . [ff] . [ff] . [00] @ [40] . [01] . [00] . [00] . [00] . [10] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Send: P [50]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv:
################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9205
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: Send: V [56] . [a0] . [00] . [fc] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: V [56] . [a0] . [00] . [fd] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: V [56] . [a0] . [00] . [fe] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: V [56] . [a0] . [00] . [ff] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: erasing chip
avrdude: Send: V [56] . [ac] . [80] . [00] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: B [42] Y [59] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [00] . [00] . [ff] . [ff] . [00] @ [40] . [01] . [00] . [00] . [00] . [10] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Send: P [50]   [20]
avrdude: Recv:
avrdude: Recv:
avrdude: reading input file "C:\DOCUME~1\Paddy\LOCALS~1\Temp\build6213415455488635988.tmp\Test0.cpp.hex"
avrdude: writing flash (770 bytes):

..
lines of sending data
..

avrdude: Recv:
avrdude: Recv:

avrdude done.  Thank you.

smeezekitty,

Is there an easy way for me to tell what fuses have been outputted by AVRDUDE? Are they burried in the hex file? I can't find E2 DF and FF in any kind of proximity.

I looked at the engbedded site when I added to the boards.txt file and I put in

Code:

atmega48.bootloader.low_fuses=0xE2
atmega48.bootloader.high_fuses=0xDF
atmega48.bootloader.extended_fuses=0xFF

Which are actually the default values according to atmel's datasheet. However the fact that there is a .bootloader. in there and I didn't burn a bootloader made me think that perhaps these hadn't been picked up by the compiler.

justone,

Well it kind of worked IF I disconnected anything from PD2. If PD2 is connected to Vcc, at any voltage (through resistor) then nothing seems to work and the program restarts when the voltage drops again. So for some reason the program did seem to start and run with PD2 disconnected and Vcc 5V (but not 4.3V) however when it went to sleep I had to reconnect and then disconnect PD2 to Vcc to wake it up. What the circuit should do is ignore anything on PD2 UNLESS asleep so this situation is unworkable. So it does sound a bit like brown-out but dependent on the signal on PD2. I suspect it's more to do with whatever voltage finds itself into the internal circuitry of PD2 that's doing the resetting when PD2 is left floating than real brown-out. Why would brown-out be dependent on the voltage on PD2?

When PD2 is connect to 0V the 'proper' sketch runs fine on two cells (2.52V) including sleep and wakeup on interrupt although the LEDs are a bit dimmer. With PD2 not connected there isn't a flicker that I can determine. But if I included in the setup()

Code:

digitalWrite(pin0 + (analogRead(0))%8, HIGH);
delay(500);

It lit random LEDs every half second. i.e. it seemed to be resetting itself as soon as it started to do any 'work' and causing some internal voltage drop that triggered the PD2 issue.

and for completeness this is the hex file for the minimalist script above http://www.eldwick.org.uk/sites/default/files/Test0.cpp.hex

justone,

To be fair I have mangled some components from the Eagle library with a use-able footprint i.e. capacitor for tiltswitch!

I found the verbose option first attempt (shift+'play'). The hex file means little and although I probably have a disassembler in amongst the AVR stuff, the assembler wouldn't mean a great deal more! It takes this posting over the limit if I put it in a code box so I have saved it here:http://www.eldwick.org.uk/sites/default/files/WindCharm2.cpp.hex

justone, well yes that's what I would have thought but I can't see it in my code. For instance this (entire sketch)

Code:

void setup() {
  pinMode(2, INPUT);
  pinMode(7, OUTPUT);digitalWrite(7, HIGH);
}
void loop() {}

doesn't work if PD2 is high. But is fine if I ground it. (I've tried it without the pinMode(2..)

So it could be something the compiler has created, or something left over from first uploading a sketch with an interrupt on that PD2. Though that latter doesn't really make sense as the symptom appeared as soon as the sketch was first uploaded on a fresh chip and the interrupt setup only happens after it's been running for a few minutes. In fact I am pretty sure that the interrupt isn't causing the problem. Still could be a high voltage on PD2 before the sketch had been uploaded (tried to keep it grounded but might have let the wire slip as the lights did flicker.) However it now connects to Vcc through a 100k resistor.

Don't think the brown-out is set by default on the ATMEGA48

I have increased all the resistors now as per the following non-working circuit:

and this circuit which works fine (have to change PD3 to input before setting interrupt and then to output as soon as it wakes.

Except that when I tried the simplified 'non interrupted' sketch above it displayed the same problem.

Other possible culprits:
Leaving the reset unconnected is a bit sloppy but it is pulled up internally so would probably give only very intermittent problems (if any).
When first connected for programming PD2 may be connected to 5V (through 10k, depending on whether tilt switch is open or closed) prior to setting as input or output but it would seem odd for this to break it.
8xI/O pins are connected to ground via 22ohm and 3.8V LEDs This should draw a manageable current with 4.3V supply but is on the top side while all are lit and definitely too high while connected to the programmer 5V! I think I'm settling on this as suspect #1

Modified the sketch to use PD3 (int 1 rather than int 0) and kept PD2 grounded all the time and it all seems to work as expected. I'd still be glad of any ideas why.

I might try increasing the resistances on the LEDs as it doesn't really need to be quite so *blindingly* bright and it might be getting quite near the 200mA limit when all the lights are on (and following CodingBadly's intuition). Also make the batteries last longer. Though this wouldn't have been an issue in the test sketch where I only switched on one LED at once.

lego mindstorm?

smeezekitty, Yes. Dropping supply voltage was my first suspect (as I didn't think it could be anything to do with using the PD2) however the supply is good and near and when measured actually goes up when the LEDs flicker. With a .1uF capacitor across the supply I would have expected to see it drop if Vcc was dropping for long enough to restart it.

I have made up another circuit using a fresh atmega48 and it displays identical problem so less likely due to overheated/damaged chip.

I have disconnected the circuit from PD2 (in preparation for using PD3 as the wakeup pin instead as that didn't seem to give the headaches when I did the simple test) However the sketch now doesn't run at all when the batteries are in (half illuminated LEDs all the time) BUT when connected to the 5V from the arduino as avr for programming seems to run fine (eventually stops though, poss as it tries to sleep). So it looks like it might be something to do with power supply.

It runs on batteries fine if I ground PD2. Battery voltage 4.3V. Haven't changed the sketch yet to use PD3 and not look at PD2. Any ideas gratefully accepted!

Quick test sketch using input on PD2 and just switching on and off LEDs in order resets whenever PD2 changes low to high. If I keep PD2 grounded and use input on PD3 then it seems to work as expected and doesn't reset. Allowing PD2 to go high resets the program.

Interestingly if PD2 goes high fleetingly (i.e. tilt switch only just opening) all the LEDs flicker as before but the sequence does not re-start. i.e. the value of the variable for which LED to switch next is remembered. However it does increment as if PD3 had been set high!!

Maybe the next step is to try a different chip?

Code:

const int pinIn = 3;
const int pin0 = 4;
int offSet = 0;
boolean flipFlop = false;


/*********************************
*
*********************************/
void setup() {
  pinMode(pinIn, INPUT);
  for (int i=0; i < 7; i++)
  pinMode(pin0+i, OUTPUT);
//  digitalWrite(pin0, HIGH);
  delay(500);
}

/*********************************
*
*********************************/
void loop() {
  int buttonState = digitalRead(pinIn);
  if (buttonState == HIGH && flipFlop == false) {
    digitalWrite(pin0 + offSet, LOW);
    flipFlop = true;
  }
  else if (buttonState == LOW && flipFlop == true) {
    offSet = (offSet + 1)%7;
    digitalWrite(pin0 + offSet, HIGH);
    flipFlop = false;
  }
}