Atmega8 difficulties reading PORTC *RESOLVED*

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

Well..., I'm beginning to doubt my sanity. A very simple deal:
DDRC = 0xFF;
PORTC = 0;
port_val = PINC;

And yet..., and yet, bits 4&5 (port_val) *refuse* to be read as zero! No TWI(which uses those bits)stuff going on to befoul things. I'm stumped...slightly suspicious that that the SCL/SDA are involved, but should not be. I've also tried defining DDRC as 0x00, *grounded* those pins and PINC bits 4&5 remain at '1' state. I figured it must be a blown chip, plugged in another..., same deal. This is true both on STK500, and a stand-alone board, which has *nothing* tied to those pins. At a loss, and under pressure... Have I overlooked something obvious?? Some fuse thing? Helppppp!
John

Last Edited: Sat. Jun 14, 2008 - 11:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you sure that it is bits 4 & 5 and NOT bits 6 & 7? These bits are not available in a PDIP chip.

Seeing that you are doubting your sanity I'll add a bit more fuel to the fire. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Thanks for the reply, John. Yup, checked and re-checked. 6 left alone as Reset, 7 (as you point out) is absent on pdip.., which is what I'm using. This is nutty...,simplest part of the whole deal..., but not working. I'm beginning to wonder if my chips are bad. One can only repeat this experiment so many times. I remain suspicious of the fact that the (seemingly) malfunctioning pins are SCL/SDA. But I've made sure that TWCR is clear...

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

Actually....
I have noticed that there MUST be some "gap" between setting port pins and then reading them back in. If the read happens immediately after the set (PORTC=0) then the previous value in PINC is read instead. A single NOP or any other instruction will do the trick.

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

Quote:

I have noticed that there MUST be some "gap" between setting port pins and then reading them back in. If the read happens immediately after the set (PORTC=0) then the previous value in PINC is read instead. A single NOP or any other instruction will do the trick.

Good catch--on AVRs you always need to wait a cycle. In practice it comes up so seldom that I read right by it.

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

Ok, so as a matter of interest HOW do you ascertain that those pins are read high as the M8 does not have any debugging facility? Do you have an ICE50 by any chance? Or are you echoing those bits to another port?

If so, could the error be elsewhere?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
If the read happens immediately after the set (PORTC=0) then the previous value in PINC is read instead
I have over-abbreviated the problem, I'm afraid. The difficulties lie in doing a simple byte-wide read of the port. Configuring the port as outputs, and then reading PINC was simply an effort to figure out what is going on. In reality, the port is configured (DDRC = 0x00;) at initialization, then periodically polled much later. Note that the inputs are pulled hard to ground when tested.

Quote:
HOW do you ascertain that those pins are read high

The byte is passed to USART, processed externally. FWIW (not too much, I know...)everything works swell in Studio's simulator. Plenty of other data is being handled in the same manner, the USART I/O and data handling are fine.

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

Resolved. Humility is supposed to be good for the soul.., I'm not so sure about *humiliation*. My thanks to all who took the time to reply to my posts, and suggested solutions. If I had posted all of the code, any of you would have spotted the problem immediately. I slipped into decimal mode in the wee hours while masking the read PINC bits: 0x01,0x02,0x04,0x08,0x16,0x32 which made results inexplicably weird. My apologies and thanks again to all.