sanity check on pd7 atmega32u4

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

I set up my ports like so

    DDRD &= ~0x80;// in
    DDRD &= ~0x40;// in
    DDRD  |= 0x20;// out
    PORTD |= 0x40;//latch
    PORTD |= 0x80;//clock
    PORTD |= 0x20;//data

I can & PIND with 0x40 just fine but 0x80 thinks its always low. I can clearly see on the analyzer that it goes high when expected and hits 5 volts.  but the code has another option. I thought maybe the pins had two states but from the data sheet it clearly is a i/o pin and with the same capabilities as pd6. Happy to provide more relevant code here but am I missing something.

 

Should probably add I'm using this but I did check the pin on the chip to breakout point and its good.

 

Also I do not have an external pull up but looks to be ok without, maybe I'm wrong. I attached what I see on the wire.

Top line is PD7 second is PD6, blue is debug. When the debug goes high, it is put in to a WHILE_CLOCK_IS_LO loop. You can see the line is high and even goes lo but debug runs its loop anyways.
T

This topic has a solution.
Last Edited: Sun. Dec 15, 2019 - 09:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Instead of all those read-modify-write oprations, why don't you just do:

DDRD = ....
PORTD = ....

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

I can do that for a test but other then the fact of "human error" I see no advantage. 

 

For the record I tried with

    DDRD = 0;
    PORTD = 0xff;

but get the same results. Also added some debug info above.

 

Last Edited: Sun. Dec 15, 2019 - 12:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is connected to PD7?  Is this a board of your own creation?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Its is a Nintendo console (the original one) I'm connecting to a controller port on the system that uses a very well known C,L,D paradigm.  That top line in the image is the clock, the one that  works is the latch.

 

I tried to eliminate that by manual holding the pin high and low and I'm still in the same situation.

Last Edited: Sun. Dec 15, 2019 - 12:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the relevant code but I really dont see what is wrong here?   

 

 

#define MAX_TIME 32000
#define WHILE_CLOCK_IS_HI while ( timer < MAX_TIME &&(PIND & 0x80)        ) {timer++;};    
#define WHILE_CLOCK_IS_LO while ( timer < MAX_TIME &&(PIND & 0x80)==0x00) {timer++;};    
#define WHILE_LATCH_IS_LO while ( timer < MAX_TIME &&(PIND & 0x40)==0x00) {timer++;};    
#define WHILE_LATCH_IS_HI while ( timer < MAX_TIME &&(PIND & 0x40)         ) {timer++;};   

  

    DDRD &= ~0x80;// in
    DDRD &= ~0x40;// in
    DDRD  |= 0x20;// out
    PORTD |= 0x40;//latch
    PORTD |= 0x80;//clock
    PORTD |= 0x20;//data

 

    int   timer = 1;
    WHILE_LATCH_IS_LO// this works as it should
    
        timer = 1;
        PORTF |= 0x01;//debug hi
        WHILE_CLOCK_IS_LO   //<-- should break when HI but the loop keeps going
        PORTF &= ~0x01;//debug lo
        while(1);//debug halt

 

 

This intend code it to do this

    
        timer = 1;
        PORTF |= 0x01;//debug hi
        WHILE_CLOCK_IS_HI   //<-- but this causes the loop to exit right a way, when clearly it should loop until the clock falls or max time.
        PORTF &= ~0x01;//debug lo
        while(1);//debug halt

 

 

 

Last Edited: Sun. Dec 15, 2019 - 12:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why are you fooling around with timers and such?...first just make a program that ONLY looks at PIND & see if that works & detects hi/lo.

You neglect to mention what chip you have.

 

Also, it is better to specify the number of bits  for  timer1 (8 or 16)  so you don't get fooled.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Dec 15, 2019 - 08:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have pretty much have taken it all down to motoring PIND at this point and the chip simply will not see any state on PIND  ( 7th bit ) other than low. I can however, set out and the bit on PORTD will go high or low as seen on my scope. It seems only the reading condition fails.

I also have swapped chips (atmegas32_u4) with the same results.

 

Last Edited: Sun. Dec 15, 2019 - 06:14 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have both avcc pins tied to VCC on your board?

jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

This is a dev board but I think that was the issue. Both dev boards had the problem but pressing down on the chip fixes it. A reheat of the chip fixed it permanently.

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

A reheat of the chip fixed it permanently.

You ordered the temperature sensing option on PD7 !

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!