SAMD51 USART pin availbility

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 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? 

 

 

 

 

  • 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

  • 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
  • 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...)

 

  • 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!

  • 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. 

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

 

Attachment(s):