Peripheral/GPIO Output Driver Bug?

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

We are using the AT32UC3A, and I think I've discovered a bug in the GPIO/Peripheral multiplexing. Don't know if it applies to all pins, but it does seem to affect pin PA17 (SPI1-MISO).

The problem is that if I program this pin as a GPIO output (output driver is enabled) and then program it to be function B (SPI_1) but I don't hit the ODERC register to explicitly turn off the GPIO output driver, the output driver remains on, and the pin has whatever state is set in the output value register (OVR). This obviously causes the SPI to malfunction - it reads a constant value. We added code to explicitly disable the output driver (set the bit in ODERC)and that fixed the problem.

According to the datasheet (both the text at 22.4.4 and the diagram in Figure 22-1), setting the pin as peripheral function should give the peripheral control of the output driver enable and the output value. In other words, what is set in the ODER and OVR registers should be irrelevant. That appears to be incorrect "“ at least on this one pin (PA17).

Can anybody corroborate this behavior? Is this a bug, or is this by design?
Thanks.

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

I think this behavior comes from the design. Datasheet p. 189 (UC3A1/0) says:

Quote:
The example below shows how to configure a peripheral module to control I/O pins. It assumed in this example that the USART receive pin (RXD) is connected to PC16 and that the USART transmit pin (TXD) is connected to PC17. For both pins, the USART is peripheral B. In this example, the state of the GPIO registers is assumed to be unknown. The two USART pins are therefore first set to be controlled by the GPIO with output drivers disabled. The pins can then be assured to be tri-stated while changing the Peripheral Mux Registers.

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

You didn't mention GPER. What are you doing with it? The coresponding bit in GPER must be 0 to let a peripheral use the pin.

22.5.2 GPIO Enable Register
Name: GPER
Access: Read, Write, Set, Clear, Toggle
• P0-P31: GPIO Enable
0 = A peripheral function controls the corresponding pin.
1 = The GPIO controls the corresponding pin.

Letting the smoke out since 1978

 

 

 

 

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

Hello,

could you please write your code, how did you correct the bug?
I´m programing a AT32UC3L032 and i have the same problem like you. I supposed that it will function after writing the correct code, but it seems that the device is not working as desired. I´m a beginner in uC-programming , that´s because i don´t know where i should make the changes.

thank you for your answer.