NerdKits - electronics education for a digital generation

You are not logged in. [log in]

NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.

Support Forum » PORTB NOT RESPONDING CORRECTLY

November 27, 2009
by gnkarn
gnkarn's Avatar

HI, I am experimenting with a led array, in my configuration 6 leds are managed by portC and the two msb are managed by port B pins 3 and 4.

I run the program using the simulation environment in AVR studio, and it works perfectly, when I run the program from the micro, the port C leds works fine, but the port B leds stays on all the time.

More strange is that , I added an initialization code segment to test all leds, and it works perfect, but after this, leds 6 and 7 stays on all time.

Any possible incompatibility with PORTB and the serial communication routines include in the library?, any library function "included" that makes abuse of portB ? thanks

November 27, 2009
by pbfy0
pbfy0's Avatar

You could try setting PORTB to 0:

PORTB = 0;

at the beginning of your code, which would turn all off.

November 27, 2009
by gnkarn
gnkarn's Avatar

During The initial phase I blink all LEDs and works perfect , what puzzles me is that after this portb changes it's behaviour also consider that under simulation the code works fine thanks

November 27, 2009
by gnkarn
gnkarn's Avatar

PROBLEM SOLVED, just for the record in case it may be of help

This is my problem analysis: as im using a 74ls374 to "latch" the port outputs , because my next step is to multiplex several 8 bits outputs, and I am using PORTB pins as data pins 3,4, and also to control (pins 0,1,2) ; in my code I was at the same writing the data to port B, and triggering the control lines to latch the data.

My assumption is that there is a timing issue involved here, this must be two separate code lines in order to allow for proper edge triggering, so once I changed my code in order to perform this two tasks in separate lines instead of doing all on the same code line, it start working right.

This also explains why I wasn't able to see the problem in the simulator, because in the simulator you can see the PORT status, but not the actual "latch status".

Gustavo

November 28, 2009
by NK_EK
NK_EK's Avatar

Hi,

I have a similar problem on pins PB2 & PB3. For some reason when I switch PB2 high (PORTB |= (1<<PB2);) PB3 ALSO goes high, even though I specifically set it low (PORTB &= ~(1<<PB3);). PB2 is set as OUTPUT (DDRB |= (1<<PB2);) and I've even tried to switch PB3 to input, but no luck.

All the other pins seem OK. I will try and test if I can read input from these two pins & report back.

Thanks in advance.

Ernest

November 28, 2009
by NK_EK
NK_EK's Avatar

Now I'm pretty I screwed something up somewhere. The pins do not get input AT ALL! They work fine as 1 output pin, but no longer as input.

Any help will really be appreciated.

November 28, 2009
by NK_EK
NK_EK's Avatar

PRETTY SURE that should be...

November 28, 2009
by gnkarn
gnkarn's Avatar

For some reason I have to install "pull down" resistors on the PORTB pins , for it to work properly... It should be a good logical explanation for this ...

November 28, 2009
by NK_EK
NK_EK's Avatar

Is there a way to completely reset the MCU (168) - all the pins, registers? I don't quite understand the datasheet. It speaks of a RESET by setting the RESET pin (pin 1) low for more than a clock cycle. Do I remove the +5V from pin 1 & restart the MCU? I'm trying to undo any recoverable mistakes that I may have made.

November 30, 2009
by hevans
(NerdKits Staff)

hevans's Avatar

Hi NK_EK,

The surest way to reset the chip is to disconnect the power, and plug it in again. You can also use the RESET pin (pin 1). Our instructions have you put a wire from pin 1 straight to +5, this will keep this pin high and keep you from resetting your chip. If you want, you can set up a pull up resistor from the pin to +5 instead of the wire. Then you can take another wire and quickly ground pin 1 when you wish to reset the chip (For a more elegant setup, you can hook up a switch).

Every time you reset the chip everything in RAM is cleared (or at least no longer valid), registers are reset, and your program starts again from the main() function. Anything in Flash or EEPROM will be unaffected. Let us know if you have any other questions.

Humberto

November 30, 2009
by NK_EK
NK_EK's Avatar

Humberto,

Thanks for the reply.

I tried that, but the two ports (PB2 & PB3) seems to be shorted internal to MCU. As I described before, there seems to be a "bleed" between the two - when I connect two LED's and blink them alternately, the one on PB3 stays dimly lit (it does flash, but never goes completely dead). I can also not read input from these two pins.

I removed the MCU from the breadboard and put it into a spare breadboard - same result. I took a spare MCU and loaded the exact program on that one, and it's working fine.

So it seems to me that in my experimenting I've managed to damage the chip although it's not completely ruined. I'll continue to use it for experimenting and keep the other 168 for my LED Marquee.

Again, thanks to everyone for the help.

Ernest

December 01, 2009
by hevans
(NerdKits Staff)

hevans's Avatar

Hi NK_EK,

How are you "turning off" the pins? Remember that these are digital outputs, that means that a logic low does not necessarily have to be 0V. To turn the LED completely off. To make sure the LED goes completely off try turning the pin into an input pin temporarily (and turn off the pullup resistor). That will make sure no current flows through the pin, and will hopefully turn your pin completely off.

It is possible you fried that bank of pins. But it doesn't hurt to check to make sure.

Humberto

December 02, 2009
by NK_EK
NK_EK's Avatar

Humberto,

Again, thanks for the reply.

You can look at the main() function that I use here: pastebin. Sorry for the lack of comments - I just slapped this together to test.

I took a video and uploaded it here: YouSendIt.

Thanks for your help so far.

Ernest

December 02, 2009
by NK_EK
NK_EK's Avatar

BTW, the same thing happens the other way round - if I just blink PB2 (commented in the above code) with PB3 supposedly 'off'.

December 03, 2009
by pbfy0
pbfy0's Avatar

I think you have PB2 and PB3 set as input. replacing line three with this:

DDRB |= (1<<PB2) | (1<<PB3);

should fix your problem (I think) note: if it says &lt;, that means a less than

December 03, 2009
by hevans
(NerdKits Staff)

hevans's Avatar

Hi NK_EK,

It looks like you did manage to short the pins internally. There is pretty much nothing else that could explain what you are seeing.

Humberto

December 05, 2009
by NK_EK
NK_EK's Avatar

Humberto,

Thanks for the help (again). Yep, I sure did something silly somewhere - just wish I knew where so that I don't repeat it :-).

Luckily the other pins work fine, so I can still use the chip for testing/experimenting.

Ernest

December 27, 2009
by BobaMosfet
BobaMosfet's Avatar

Ernest-

It would be useful to know what your schematic is-- are you using an AVRisp MkII or your programming, or something else? In other words, is anything else plugged into your PORTB pins?

Remember also, that you must use a resistor in series with any LED you use, not only to protect the LED, but also to protect the MCU pin- excessive current (not voltage) is what will kill your device.

December 28, 2009
by NK_EK
NK_EK's Avatar

BobaMosfet,

Thanks, but there is nothing else connected to any of the PORTB pins.

I thought long and hard about what I could have done wrong, and the only 2 things I could think of was the time I tried to run a small hobby geared motor off the MCU (but I cannot recall which pins I used) or just using the LED's without resistors (maybe even switching the anode & cathode).

But as I say, I can't remember exactly what I did, but this I know: I will definitely be more careful in future and make sure that everything is connected as it should be before applying power.

Thanks for the help!

Post a Reply

Please log in to post a reply.

Did you know that a NerdKit can take control of a remote-controlled car? Learn more...