Un-mapping an IO pin

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

Hi All ...Need some help with this issue.    

CPU = ATSAM4LC8C

 

I have a USART that gets configured by mapping the required pins using  ...

 

 #define ioport_set_pin_peripheral_mode(pin, mode) \
 do {\
 ioport_set_pin_mode(pin, mode);\
 ioport_disable_pin(pin);\
 } while (0)

 

ioport_set_pin_peripheral_mode(PIN_UART1_RX, UART1_RX_MUX);
ioport_set_pin_peripheral_mode(PIN_UART1_TX, UART1_TX_MUX);

 

USART works just fine as expected.  No problem here.  

 

After doing its job, I need to put the CPU to sleep until a minute later.    The problem is the USART drives the TX pin high .. which is connected to a resistor divider network resulting in 0.5mA current draw.

During sleep, the TX pin remains high.

 

So need to unmapp the pin most likely (don't know if it is possible to manually set the output to zero while mapped)

I have tried many things ... but the pin never releases its high value.   

For example, if I use...

 

ioport_reset_pin_mode(PIN_UART1_TX);

or 

ioport_reset_pin_mode(PIN_PA16);

or

ioport_reset_pin_mode(GPIO_PA16);  (this one causes a crash)

 

It does not work ... as the pin remains high and when I use the USART again with what should be an unmapped TX pin, the USART works fine. 

Any clues to solve this problem?  

Thanx

 

 

  

 

 

 

 

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

This probably has more to do with how the SAM4L GPIOs work than specifically with ASF - so you may be better asking in the SAM4L forum.

 

What I do in this kind of case - where RTFM doesn't help - is to step through the code[1] while watching the pin state, and see where it goes from "idle" to driving high.

 

Then you know what you need to un-do in order to get it back to the "idle" state ...

 

 

[1] That includes stepping into the ASF code.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happens if you disable the UART before sleep? Surely it will relinquish control of the pin?Or, if it then reverts to GPIO operation, you can presumably just set the output state low?

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

 

"What happens if you disable the UART"

 

I had just tried this and came back to report and noticed your comment.

 

I feel like an idiot!!!    I disabled everything except for the USART   ... so tried using usart_disable_Tx and usart_disable_rx.    It released the pin and went low state.  Fantastic!    

I had the wrong idea in my mind as I was trying to un map instead of simply disabling.     Duh!!

One thing I have noticed by watching the GPER register via ICE, is that the mapping is not released.    Still seem unable to do this, not that it matters anymore.  Just an observation.  

 

Brian

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

clawson wrote:
Surely it will relinquish control of the pin?

No, that is not "sure" at all - it is certainly not the way the SAMDs work.

 

On the SAMDs, the control of IO pins is separate from the mapping of alternate functions - and that is separate from control of the SERCOM peripheral.

 

EDIT: Just seen that it does work in the case of the SAM4L in question.

 

Which all goes to show my original point that it's not so much about ASF as about the specific chip (or family) in question...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jun 29, 2017 - 08:25 AM