Atmega8 difficulties reading PORTC *RESOLVED*

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
JohnPsmith
JohnPsmith's picture
Level: Rookie
Joined: Thu. Nov 29, 2007
Posts: 29 View posts
#1
Posted by JohnPsmith: Sat. Jun 14, 2008 - 04:04 AM
  • 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

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Last Edited: Sat. Jun 14, 2008 - 11:33 AM
Top
Bronze Markjs
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 31288 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)
Posted by js: Sat. Jun 14, 2008 - 05:03 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.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
JohnPsmith
JohnPsmith's picture
Level: Rookie
Joined: Thu. Nov 29, 2007
Posts: 29 View posts
Posted by JohnPsmith: Sat. Jun 14, 2008 - 05:16 AM
  • 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...

Top
eskoilola
eskoilola's picture
Level: Hangaround
Joined: Tue. May 6, 2008
Posts: 435 View posts
Location: Finland
Posted by eskoilola: Sat. Jun 14, 2008 - 05:29 AM
  • 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.


Yet another home page

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40565 View posts
Location: Wisconsin USA
Posted by theusch: Sat. Jun 14, 2008 - 07:38 AM
  • 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.

Top
Bronze Markjs
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 31288 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)
Posted by js: Sat. Jun 14, 2008 - 09:19 AM
  • 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.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
JohnPsmith
JohnPsmith's picture
Level: Rookie
Joined: Thu. Nov 29, 2007
Posts: 29 View posts
Posted by JohnPsmith: Sat. Jun 14, 2008 - 11:00 AM
  • 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.

Top
JohnPsmith
JohnPsmith's picture
Level: Rookie
Joined: Thu. Nov 29, 2007
Posts: 29 View posts
Posted by JohnPsmith: Sat. Jun 14, 2008 - 11:51 AM
  • 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.

Top