Environment
- MCU : TI MSPM0G3507
- IDE: IAR
- Clocking: UART functional clock = 4MHz
- Test tools: HTerm (PC host), DSO
UART Configuration
- Baud rate: 57,600
- Data Length: 8 bits
- Stop Bits: 1
- Parity: EVEN
- Oversampling: 16× (CDD_UART_OVERSAMPLING_RATE_16X)
- Flow Control: None
- Pins: TX on PA10 (configured via Port Mux during enable command);
- Default State: UART disabled at reset. TX pin becomes UART TX only after an “Enable UART Transmission” command is received.
Protocol / Command to Enable UART
- Enable Command Packet (from host): 0xA5 0x22 0xDE
- Expected device behavior upon receiving A5 22 DE:
- Send ASCII string "UART_Enable:" over UART.
- Configure PA10 as UART TX via Port Mux.
- Activate UART transmission (module enabled).
- After enable, host sends additional commands (Read/Write).
Example: Read Software Version command: 0xA5 0x22 0xA0
(Sync = 0xA5, Read ID = 0x22, Cmd = 0xA0; device should respond with version string over UART.)
Observed Behavior (Corruption on first reception)
- On first transmission, bytes sampled in the UART RX data buffer do not match what was sent.
Example 1
- Host sent: 0xA5
- DSO shows serial bits: 0101001010 (start/LSB‑first representation from HTerm)
- Device RX buffer reads: 0x5A (and sometimes 0x2D)
- 0x5A = 0101 1010 (appears like bit‑reverse of 0xA5 = 1010 0101)
Example 2
- Host sent: 0x22
- DSO shows: 0010001000
- Device RX buffer reads: 0xEE (sometimes 0x37 or 0x6E)
- 0xEE = 1110 1110 (not the transmitted pattern)
- After resending the same command 2–3 times, device starts responding and subsequent traffic is often correct.
Expected Behavior
- Device should correctly receive the first packet (0xA5 0x22 0xDE) and immediately:
- Send "UART_Enable:"
- Configure PA10 as UART TX
- Enable UART transmission
- Subsequent commands (e.g., 0xA5 0x22 0xA0) should be processed on the first attempt without re‑transmission.
