Fix no response on SERIAL* for SKR 1.3 / 1.4 / LPC176x with high BAUDRATE

[mh-dm]

Description

Fix no response on SERIAL* for SKR v1.3 / LPC1768 with BAUDRATE > 250000
Fix no response on SERIAL* for SKR v1.4 Turbo / LPC176x with BAUDRATE >= 1000000

Requirements

Tested on SKR v1.3. After fix verified 57600, 115200, 250000, 460800, 500000, 921600 BAUDRATEs work on SERIAL_PORT 0.
Edit: Tested on SKR v1.4 Turbo which uses LPC1769. After fix verified 57600, 115200, 250000, 460800, 500000, 921600, 1000000, 2000000 BAUDRATEs work on SERIAL_PORT 0.

Benefits

SKR v1.3 and v1.4 Turbo (likely many LPC176x) can now use high BAUDRATEs on SERIAL_PORT*.

Related Issues

#22283

[ellensp]

shouldn't this be fixed in the platform and for all uarts?
@p3p thoughts?

[mh-dm]

The fix is in LPC1768/MarlinSerial.h which is used for both LPC1768 and LPC1769. My best understanding is that the issue is LPC176x specific. I still need to verify whether the issue and fix applies to SKR 1.4 Turbo / LPC1769.

(Edit: removed section that was wrong)

[mh-dm]

I've now tested SKR v1.4 Turbo / LPC1769 and turns out it's only somewhat affected:

• on bugfix-2.0.x BAUDRATEs of 115200, 250000, 460800, 500000, 921600 work. BAUDRATE 1000000 does not work
• with the fix, BAUDRATEs of 57600, 115200, 250000, 460800, 500000, 921600, 1000000, 2000000 (!) work

The fix works and improves behaviour for high BAUDRATEs.

[mh-dm]

Yes, we should do all UARTs. I just tested high BAUDRATEs and:
CLKPWR_SetPCLKDiv(CLKPWR_PCLKSEL_UART1, CLKPWR_PCLKSEL_CCLK_DIV_1);
fixes no response on UART1 (pins P0_15 and P0_16 within EXP2 connector) on both SKR v1.3 and v1.4 Turbo and
CLKPWR_SetPCLKDiv(CLKPWR_PCLKSEL_UART3, CLKPWR_PCLKSEL_CCLK_DIV_1);
fixes no response on UART3 (pins P4_28 and P4_29 within WIFI connector) on SKR v1.4 Turbo. Haven't tested UART2 as the pins are already used by other things but CLKPWR_PCLKSEL_UART2 is also defined in lpc17xx_clkpwr.h and there's no reason to think UART2 would work differently.

[p3p]

shouldn't this be fixed in the platform and for all uarts?

Indeed, as this appears to be a general issue this should probably be in the LPC176x framework rather than Marlin, having a quick look at the linked issue its just upping the UART peripherals base frequency to improve the final baud rate error, I don't think there is any downside to doing that.

[mh-dm]

@p3p I've created p3p/pio-framework-arduino-lpc176x#47 . Please advise.

[p3p]

Will be fixed in the LPC176x framework