SAMD51 USART pin availbility

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
MarkR86
MarkR86's picture
Level: New Member
Joined: Thu. Oct 14, 2021
Posts: 4 View posts
#1
Posted by MarkR86: Thu. Oct 14, 2021 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been working on a rather pin constrained project with multiple serial ports. I've encoutered problems setting up some receive-only USARTS, as certain pins don't seem to work for this purpose. 

 

I'm using a 64 pin device (ATSAMD51J19A). I've identified 4 pins which do not seem to seen by the USART peripheral (no data is received, no status changes or interrupts are issued).:

PA04 (SERCOM 0, IOSet 3, pad 0)

PA05 (SERCOM 0, IOSet 3, pad 1)

PB02 (SERCOM 5, IOSet 6, pad 0) 

PB16 (SERCOM 5, IOSet 1, pad 0) 

 

I've verified that when accessed through PORT GPIO, the signal is present and seen by the MCU on these pins. The pin MUX is performed after enabling the USART, and I've verified that the PINCFG/PMUX registers are correctly set. 

 

Other pins in the same IOSets may work, e.g. PA06 (SERCOM0, IOSet 3, pad 2)  and PB17 (SERCOM5, IOSet 1, pad 1) work fine. PB03 has other issues (MCU shows erratic behavior, hard faults or resets, when any external signal is applied to this pin, whether or not a USART is Muxed to it). I suspect the PB03 issue is a different one.

 

Any ideas as to what is going on? I've not seen anything which would explain this in the datasheet or errata? 

 

 

 

 

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Top
malaugh
malaugh's picture
Level: Wannabe
Joined: Thu. May 19, 2016
Posts: 87 View posts
Posted by malaugh: Sat. Oct 23, 2021 - 03:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Table 6-1 in the data sheet shows how the GPIO pins can be mapped to the peripherals.    The table shows PB16 can be mapped to SERCOM5 pad 0 or PB02 can be mapped to SERCOM5 pad 0.  You cannot map the both PB16 and PB02 to SERCOM5 oad 0, unless you want the same signal on both pins.  You need to map a GPIO to pad 1 or pad 2 then use the SERCOM CTRLA register to map the pads to the Tx and Rx functions of the UART.

John Malaugh

Top
MarkR86
MarkR86's picture
Level: New Member
Joined: Thu. Oct 14, 2021
Posts: 4 View posts
Posted by MarkR86: Sun. Oct 24, 2021 - 07:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. Thanks for the reply.

 

I think you misunderstand by point. I have been looking for a pad (any pad) which can be mapped to the Rx port of a USART. I've seen the table 6-1, but not all these pads appear to work for all SERCOM's.

 

For example, if I configure SERCOM0 to use PA04 as pad0, PA05 as pad1 and PA06 as Pad2, then setting pad 0 as Rx pad doesn't work, setting pad 1 as Rx pad doesn't work, but setting pad 2 as Rx pad does work. 

Similarly configuring SERCOM5 to use PB16 as pad 0, and PB17 as pad 1, I can set Rx pad as pad 1, but if I set Rx pad as pad 0, it doesn't work.

 

I've verified on all the other SERCOM's that pad 0 does work correctly as Rx pad, provided that Tx is disabled. It also doesn't explain why PA05 doesn't work Rx, as it maps to pad 1 of SERCOM 0. 

 

Interestingly, PA04 does work as Tx, even though it doesn't work as Rx.

Last Edited: Sun. Oct 24, 2021 - 07:17 PM
Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 5344 View posts
Location: SF Bay area
Posted by westfw: Mon. Oct 25, 2021 - 04:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any ideas as to what is going on?

No, not really.  Can't see your code. though :-(
Are you sure you're getting the PINMUX correct (SERCOM vs SERCOM_ALT)?
It's vaguely disconcerting that the PAD selection doesn't have a "not on a PAD" setting; I'm not sure what happens when the RX Pad and TX (or other function) pad are set to the same pin.
Have you tried other TXPO settings?  What about setting both TXPO and RXPO to PAD0, and just not transmitting anything?
BOTH clocks are enabled?  (GCLK_SERCOMn_CORE and CLK_SERCOM_APB)?  (probably you're not seeing enough failures to have omitted that...)

 

Top
DrDatasalad
DrDatasalad's picture
Level: Wannabe
Joined: Mon. Jun 8, 2009
Posts: 95 View posts
Location: Planet of the Apes
Posted by DrDatasalad: Wed. Nov 3, 2021 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

thank you for posting your experience.
I am using SAME54Xplained board and also one USART has RX not functioning.

But in my case it is SERCOM1, PC23: RX.

 

It could be an "undocumented feature" aka yet reported errata. Looks like the peripheral pin-mux lost some pins.

 

As I am making the layout for the SAME53J18, I am now afraid, to fall in a similar pit...

Surprise: As soon as one's doing it correctly - it works!

Top
MarkR86
MarkR86's picture
Level: New Member
Joined: Thu. Oct 14, 2021
Posts: 4 View posts
Posted by MarkR86: Mon. Jan 17, 2022 - 01:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally, I think I have solved this problem. It proved extremely difficult and intermittent, and seemed to happen with clean projects and minimal code, as well as in more complex projects and a custom PCB. 

 

What I think the issue was that there was a small amount of initialisation done outside of my code, as I had used atmel start to build an eclipse project. The atmel start project seems to have included some peripheral setup which I was not aware of and had ignored as I was just doing bare metal programming. As a result in some situations, when my code set up the pin MUXing, two IO pins may have ended up MUXed to the same SERCOM pad, leading to unpredictable behavior of the SERCOM.

 

Although this first came to light with USART operation, i only had sufficient clues to solve this on another project where I was using I2C.  I found the SERCOM would appear to crash and just emit a continuous SCK waveform, while failing to interacting with software/generate interrupts. The clue in this case was that the SERCOM would malfunction only when a push button was pressed at boot time. In this case, my code did GPIO muxing after I2C init, so there was a short period where both pins were MUXed to the same SERCOM, the presence of an external signal on the second pin while the I2C was attempting an operation would cause it to enter an unstable state. 

Top
tinek
tinek's picture
Level: New Member
Joined: Mon. Jan 17, 2022
Posts: 3 View posts
Posted by tinek: Sat. Jan 22, 2022 - 06:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Attachment(s): 

Plain text icon Sam4.txt
Top