PB6 and PB7 as serial problem

Using Arduino Microcontrollers
1

Hello everyone. I'm having problems using PB6 and PB7 as digital IO for serial communication with my SIM800L GPRS module with my ATmega 328p. After doing some testing I've got this information: PB6 works as RX and TX. PB7 is unable to work as RX or TX neither. Serial communications work well using PB6 as RX and PD5 as TX or PD5 as RX and PB6 as TX. I want to ask if someone knows about this behavior and how could I fix it. For now, I'll patch it at the PCB.

This are my fuses configuration:
low_fuses=0xE2
high_fuses=0xDA
extended_fuses=0xFE

2

Pb6 and pb7 are normally connected to the crystal. Are your fuses setting the chip to use the internal oscillator? And is this custom-built hardware?

3

Yeah, he's using the internal oscillator, E2 is internal 8mhz. If he had it set to use a crystal, his board wouldn't be working at all

If it's not custom hardware, did you remove the crystal or resonator?

What core/board def are you using, and what software serial library?

4

DrAzzy:
What core/board def are you using, and what software serial library?

I'm using ATmega 328p from the "MiniCore" board package. I stopped using the arduino's core because I wasn't able to disable BOD whenever I set the fuses to OFF, maybe some bootloader overwrite.

Also, I'm using the standard software serial included with arduino, "SoftwareSerial.h (formerly NewSoftSerial.h)" but with a 256 bytes buffer (It should not be the problem :D)

Ah! I forgot to mention, I can use both pins for normal digital writes. Today I'll try digital reads, I think it is something related to internal pullups. BTW, if it is not that, I'll asume the pins are not able to change states fast enough to deliver serial communication. I wish I could try it at AVR Studio, but the learning curve is high enough to prefer modifying the PCB.

Also, is completely custom hardware, except for software :stuck_out_tongue:

5

Update:
Using NeoSWserial give the following results: PB6 transmit, no receive. PB7 transmit, no receive.

Also, the digital input readings:

pin			PB6			PB7
		GND	VCC	UNCONN	GND	VCC	UNCONN     

no internal	0	1    *RANDOM	0	1	*RANDOM
pull up

internal pull   0	1	1	0	1	1
up

*Strange thing is, when no pullup and unconnected, after feeding VCC to ports they remain for a while in HIGH (as expected), and then fall down to LOW, but, they don't start to read random HIGHs and LOWs, it is just like they where pulled down. If I do the same exercise on PB5 and PB4 I get the expected "random" HIGHs and LOWs. So, I think PB [6:7] are the best for wiring buttons xD (pun intended, unconnected pins are ALWAYS unpredictable).

6

Why do you care what is read by an unconnected input?

Everyone else connects inputs properly, using pullups or pulldowns, or active circuitry to define the voltage levels.

7

jremington:
Why do you care what is read by an unconnected input?

When you experiment with something is necessary to test all possibilities. For example, if unconnected pins while not using pullup rose to HIGH would mean a problem on pin state behavior, so next check would be to test voltage on pins. Since there is no problem, I don't need to read them. That's how I sample some maybe-useful data and saved a couple of steps, the ones I spend writing this xD

Edit: It was also necessary to test internal pullups, and, well, there is only one way to test them, right?

Edit 2: I'm working with just an atmega 328 wired in a breadboard. Breadboard capacitance is assumed to do not interfere with serial communication (has demonstrated with serial in other pins)

8

When you experiment with something is necessary to test all possibilities.

That is impossible, because you can't control all the details.

What an unconnected pin sees depends on contaminants on the board, the IC package, the wiring or circuit traces, moisture, local electrostatic and electromagnetic fields, etc. and is different for every pin.

Connect your pins properly and verify proper operation under those circumstances.

As a general rule in working with ICs, unused pins should ALWAYS be properly terminated unless you are specifically directed to do otherwise by the manufacturer (and the pin will be marked NC).

9

jremington:
That is impossible, because you can't control all the details.

No, it is possible as far as our knowledge can extend during experiment design.

jremington:
What an unconnected pin sees depends on contaminants on the board, the IC package, the wiring or circuit traces, moisture, local electrostatic and electromagnetic fields, etc. and is different for every pin.

And this is why you test them in controlled arrangements to see if they behave as expected. An unconnected pin should behave as an unconnected one: unpredictable but not stable.

jremington:
Connect your pins properly and verify proper operation under those circumstances.

Did you even read the other 2 tests, I mean, they where tested connected to VCC, GND through 330 ohm resistor.

jremington:
As a general rule in working with ICs, unconnected pins must ALWAYS be properly terminated unless you are specifically directed to do otherwise by the manufacturer (and the pin will be marked NC).

"experiment explanation" again

In any way, I can't see how your discussion about why not to test an unconnected pin when testing unconnected pins is going to solve my serial comm problems. So I hope you have something valuable for this topic rather than trying to feel superior to other ones.

[Edit:] Tip: Go on and try using PB[6:7] for serial comm between two atmegas 328p by yourself, because I've tried with more than 3 different and the result is the same.

10

No, it is possible as far as our knowledge can extend during experiment design.

Please don't confuse other beginners with your inexperience.

Things tend to work if you follow the rules.

11

jremington:
Please don't confuse other beginners with your inexperience.

I see, maybe you're going for the "buttons" sarcasm. I'll edit it, so any beginner will know it was a joke over an experiment. You know, there's always a beginner who gets confused why are they reading unconnected pins.

12

SoftwareSerial uses Pin Change Interrupts. I suspect that those don't work correctly on PB6/PB7...
They're defined as D20 and D21, right? And it looks like the PCxxx macros (in pins_arduino.h) have been updated to include pins up to 21, but I don't see any logic to force them back into PORTB (PCMSK0):

#define digitalPinToPCICR(p)    (((p) >= 0 && (p) <= 21) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 2 : (((p) <= 13) ? 0 : 1))
#define digitalPinToPCMSK(p)    (((p) <= 7) ? (&PCMSK2) : (((p) <= 13) ? (&PCMSK0) : (((p) <= 21) ? (&PCMSK1) : ((uint8_t *)0))))
#define digitalPinToPCMSKbit(p) (((p) <= 7) ? (p) : (((p) <= 13) ? ((p) - 8) : ((p) - 14)))
13

westfw:
SoftwareSerial uses Pin Change Interrupts. I suspect that those don't work correctly on PB6/PB7...

Ok, I'll check down how Interrupts behave at different frequency (IMO frequency is not a thing, because baudrate configuration isn't modifying result at all), maybe there is something I missed on the datasheet. I could check that port mapping macro or do it by hand just to be sure. Taking in account that the way pins behave is relative to library, it likely points to be a software-thing. I think NeoSWserial don't use pin interrupts, but I'm not sure, so I'll take some readings and post results. Thanks

This is my board pins macro (mostly the same):

#if !defined(__AVR_ATmega8__)
#define digitalPinToPCICR(p)    (((p) >= 0 && (p) <= 21) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 2 : (((p) <= 13) ? 0 : 1))
#define digitalPinToPCMSK(p)    (((p) <= 7) ? (&PCMSK2) : (((p) <= 13) ? (&PCMSK0) : (((p) <= 21) ? (&PCMSK1) : ((uint8_t *)0))))
#define digitalPinToPCMSKbit(p) (((p) <= 7) ? (p) : (((p) <= 13) ? ((p) - 8) : ((p) - 14)))
#endif