USART0 RS-485 fails on ALT pins (USART1 OK) on ATtiny3227 #1263
Unanswered
mechatroniks-git
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I think I've exhausted this issue and believe it's either a core issue or in the silicon.
TLDR:
ATtiny3227 + megaTinyCore: USART0 works on default pins, but USART0 dies on ALT1 specifically in RS-485/XDIR mode. USART1 works in all cases.
Your register dump shows everything is configured correctly (ALT1 mux, 115200 8N1, TX/RX enabled, RS-485 enabled) and USART0 believes it transmitted (TXCIF set), but the pins never drive. That points away from config and toward a deep USART0 ALT1 + RS-485/XDIR issue (MegaTinyCore bug or silicon errata).
Hardware
Summary
RS-485 with hardware XDIR works correctly on both USART0 and USART1 when using default pin routing.
However, when moving both USARTs to ALT1 pins via PORTMUX.USARTROUTEA, USART1 continues to work correctly, but USART0 produces no output at all:
• No activity on TXD
• No activity on XDIR
• Internal USART0 state machine still completes transmissions (TXCIF asserts)
This was done to free the default USART0 XDIR pin due to an I²C SCL conflict.
Observed behavior
I had ChatGPT write me a test program that would spit out the registers on the working port using as little of the core as possible
I get this dump
Which confirms:
I'm about to give up on this chip. Anyone have any ideas for me?
Beta Was this translation helpful? Give feedback.
All reactions