ATMega8 pb6 and pb7 voltage level problem

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I am using an ATMega8 and trying to use pins 0-7 on Port B and 0-3 on PortC as outputs. (Port D is configured as Inputs). I have the internal oscillator selected, and have DDRB (and DDRC)set to 0xFF.

The problem is with Pins Pb6 and Pb7. They are set as output, and if I set them High or Low, and measure the voltage with nothing connected, they read correctly as 0 or +5v.

However, when I connect an LED and a Resistor, things get weird.

If the the led and resistor are connected to ground, the voltage on the output pin drops to around 2.6 volts, which causes the LED to only light dimly. If the led and resistor are connected to +5v, the inputs appear to "fluctuate", and the LED does not light!

I connected the led/resistor in both configurations to other output pins on Port B, and everything works fine.

I also am unable to use those pins on the STK500 board (and I did read up/search and follow the directions regarding using the XT1/XT2 pins on PortE for the STK500....) They have the same problem... they show the correct output level when disconnected, but cannot power an LED properly.

I did make sure bit AS2 in ASSR was not set. Also, when I debug in AVR studio, things work properly... this seems to be related to sourcing/sinking current?

Thoughts or suggestions?

Dave

Oh... I also tried a second ATMega8... same results.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When the load(current) on pins is too high then voltage drops down. One solution is to use some sort of buffer. ULN2003 for example is pretty good (one chip, 7 darlingtions inside, also has suppression diodes).
You could also drive your outputs through transistors or darlingtons(two transistors in one).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a feeling of having read somewhere that those pins may not sink/source the same ammount of current as "normal" I/O pins...and NO I can't find that in the data sheets :(
What current are you using to light up the led?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

qratman wrote:
When the load(current) on pins is too high then voltage drops down. One solution is to use some sort of buffer. ULN2003 for example is pretty good (one chip, 7 darlingtions inside, also has suppression diodes).
You could also drive your outputs through transistors or darlingtons(two transistors in one).

If you want to have 8 digital output you can use ULN2803.
Misaghsepehr@Gmail.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I'll give the darlingtons a try tonight.

Ironically, I was intending to use darlingtons (ULN2001) in the final config... I was just testing with LEDs before connecting them, so I could visually see the status of the pins...

The LEDs are currently drawing around 8 mA.

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If the the led and resistor are connected to ground, the voltage on the output pin drops to around 2.6 volts, which causes the LED to only light dimly. If the led and resistor are connected to +5v, the inputs appear to "fluctuate", and the LED does not light!

Quote:

Thoughts or suggestions?

I don't see any notations in the datasheet regarding limited drive on these pins.

What I would do is to pull the clock jumpers on the STK500--my guess is that the STK500 clock circuitry is fighting with your PB6-PB7 signals.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

with 8mA you don´t need a driving circuit.

Check your software if there it acidentely switches the DDDR to an input = "0"
Or post your program here.

Also check if you accidentely have enabled some alternative port functions.

Is your power supply stable? --> Maybe the brown_out gets activated.
Check powersupply, LED_output with a scope. Do you have all the VCCs and GNDs connected? Do you have all capacitors connected?

Klaus
********************************
Look at: www.megausb.de (German)
********************************

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

I don't see any notations in the datasheet regarding limited drive on these pins.

What I would do is to pull the clock jumpers on the STK500--my guess is that the STK500 clock circuitry is fighting with your PB6-PB7 signals.

Lee

Yup, tried that... same results both on the STK500 or with the chip on a protoboard...

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MegaUSBFreak wrote:

Check your software if there it acidentely switches the DDDR to an input = "0"
Or post your program here.

Also check if you accidentely have enabled some alternative port functions.

Doh! I was getting ready to post the program, when I think I found the problem in the code... Won't be home to test it for a few hours, but what I had was this...

DDRB = DDRC = 0xFF;

The code I modified was originally written for the Mega16, which I see has 8 pins on Port C. The Mega8 only has 7, and 6 is used for RESET.... so this may be incorrectly setting the DDRB register?

I am going to try changing it to:

DDRB = 0xFF;
DDRC = 0x0F; //(since I only really need bits 0-3 as outputs)

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bet the new code compiles to a smaller output too.

I had this problem once where I moved a pin, and didn't change it's initialization. It was setup as an input. However, writing a 1 to PORTB.0 would put the pullup in there, so with a volt meter, it would look like a 1 and a 0 output. A very weak output. It was in production for quite some time working like that.

Mike.

official AVR Consultant
www.veruslogic.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SteveN wrote:
Hi,

Any chance that mega16 is still installed on the STK500?

Regards,
Steve

Nope, I actually never had a mega16... the code was GPL code I found online, that I modified for the mega8.

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bnocturnal wrote:

Doh! I was getting ready to post the program, when I think I found the problem in the code... Won't be home to test it for a few hours, but what I had was this...

DDRB = DDRC = 0xFF;

The code I modified was originally written for the Mega16, which I see has 8 pins on Port C. The Mega8 only has 7, and 6 is used for RESET.... so this may be incorrectly setting the DDRB register?

I am going to try changing it to:

DDRB = 0xFF;
DDRC = 0x0F; //(since I only really need bits 0-3 as outputs)

That was definitely the problem! Everything is working now. Thanks for the help and suggestions everyone!

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but what I had was this...

DDRB = DDRC = 0xFF;


Now I'm REALLY curious. Which compiler, and what code was generated for the above sequence?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

but what I had was this...

DDRB = DDRC = 0xFF;


Now I'm REALLY curious. Which compiler, and what code was generated for the above sequence?

Lee

Well, the compiler was GCC (WinAVR)...
the assembler version is:


 31e:	a7 e3       	ldi	r26, 0x37	; 55
 320:	b0 e0       	ldi	r27, 0x00	; 0
 322:	e4 e3       	ldi	r30, 0x34	; 52
 324:	f0 e0       	ldi	r31, 0x00	; 0
 326:	8f ef       	ldi	r24, 0xFF	; 255
 328:	80 83       	st	Z, r24
 32a:	80 81       	ld	r24, Z
 32c:	8c 93       	st	X, r24
 

line 32a: was the troublemaker, i believe.

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A long way around (try -Os) but that code fragment will indeed send 0xff to DDRB and DDRC on a Mega8.

-- X gets the address of DDRB
-- Z gets the address of DDRC
-- R24 is loaded with 0xff
-- Oxff is stored (indirect) through Z to DDRC
-- 0xff is read back into R24
-- 0xff is stored (indirect) through X to DDRB

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee, are you sure?

Quote:

-- 0xff is read back into R24

Doesn't the code actually read DDRC back to R24? And since the top two bits of DDRC are zero despite the previous write to 0xff, it stores 0x3f to DDRB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Doesn't the code actually read DDRC back to R24? And since the top two bits of DDRC are zero despite the previous write to 0xff, it stores 0x3f to DDRB.

Aaah, yes--you caught it. Good one. And that would explain the symptoms! And verify the result.

I'm just a simple old farm boy, and rarely use x = y = z; just so I >>won't<< have to think about side effects. Pretty much the same with complex expressions: if I look at it after I write it and can't see what is going on, I'll tend to break it up into sub-expressions with intermediate results, and annotate each. Saves me time 6 months from now when the formula needs to be adjusted. YMMV.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey there Dave.

Glad you managed to sort out the problem. I'm having a similar issue with PB6 and PB7 not driving STK500 LEDs. I'm battling with the same problem on two separate STK500 boards using a mega8L. I didn't do anything like

DDRB = DDRC = 0xFF;

but seem to get the same symptoms as described.

I seem to remember there being a similar problem with PORTC on a mega16L chip. It was something to do with it being a low power device (hence the L) as opposed to straight mega16. Using Studio4, there were a couple of fuses that needed to be selected in this case to allow PORTC to be used on the mega16L.
Perhaps there's something similar going on with the mega8L... anyway I'll investigate further, but while I do, any ideas would be welcome.

Cheers

Jack

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

regarding the mega16 as far as I remember PORTC is the JTAG port, you did disable JTAG?

Edit: mega8 doesn't have JTAG so this is not an issue here

Last Edited: Wed. Sep 12, 2007 - 06:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It was something to do with it being a low power device (hence the L) as opposed to straight mega16.

I doubt that very much. Probably if the alternate function of some of the Port C pins is JTAG, and JTAG was not disabled.

Quote:

I'm having a similar issue with PB6 and PB7 not driving STK500 LEDs.

You must have missed what was mentioned in the original post:

Quote:

I also am unable to use those pins on the STK500 board (and I did read up/search and follow the directions regarding using the XT1/XT2 pins on PortE for the STK500....)

IIRC do a Forum search on All Words "pb6 pb7 mega8 stk500" or similar for extensive prior discussions.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jack, for mega8 pb6 and pb7 on the STK500, don't forget that they share the pins with the XTAL1 and XTAL2... and you need to wire the LEDS accordingly. (A search for 'mega8 pb6 pb7 stk500' should find the more detailed thread)

Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You must have missed what was mentioned in the original post

Point taken. Sometimes these things slip by you when there's too much mental traffic. Thanks for the advice, I'll do the recommended search.