Program gets stuck on UART initialization when using SERCOM0 on PA08 and PA09

[turbinenreiter]

I am working on a custom board on which I plan to use PA08 and PA09 as UART.

According to the datasheet, PA08 and PA09 are available as SERCOM0/IoSet1/AlternateD and SERCOM2/IoSet3/AlternateD.

However, the program hangs on setting up UART. According to my debugger, it gets stuck on this line:

atsamd_hal::sercom::uart::reg::Registers<atsame53j::SERCOM0>::enable_peripheral<atsame53j::SERCOM0> (enable=true, 
    self=<optimized out>)
    at /home/plam/.cargo/registry/src/index.crates.io-6f17d22bba15001f/atsamd-hal-0.16.0/src/sercom/uart/reg.rs:444
444             while self.usart().syncbusy.read().enable().bit_is_set() {}

I tested UART on PA00 and PA01 and got it working there, which gives me some confidence that I am configuring things correctly.
I also got UART working on PA08 and PA09 using the MPLAB IDE and tools, which gives me confidence that the hardware works or that the vendor IDE has a workaround.

I created a repo with a minimal example showing the issue:
https://github.com/turbinenreiter/atsame53-rs/blob/master/src/main.rs#L40

uart1 is the problematic one, and uart2 is the "control group" that works. Uncommenting the uart1 initialization "enables" the problem.

[transistorfet]

If the syncbusy enable bit is set, but doesn't ever clear, then according to the reference manual, it's attempting to enable the peripheral (bit is set), but is not able to synchronize (bit never clears).

My first instinct would be that the clock is not enabled for that peripheral, but given that it works with other configurations, that might not be the issue here. It's possible there is a bug in the HAL or the PAC that isn't enabling the correct clock, or that the reset state of the chip you're using is different from what the HAL or PAC are expecting.

Have you also ruled out whether a HardFault is occurring? If a HardFault occurs due to a misconfiguration, it might not panic but instead just hang.

[jbeaurivage]

@turbinenreiter: I've read through your example, and you're not enabling the right clock here:

- let clock = &clocks.sercom1_core(&gclk0).unwrap(); 
+ let clock = &clocks.sercom2_core(&gclk0).unwrap();

As an aside, the clock::v2 API makes a great deal of bugs like this one caught at compile-time.

[jbeaurivage]

Reopened, I figured I'd give people a chance to read this before closing for good.