-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
If you are using one of the MIMXRT lpuarts and call set_format to change the serial format the UART can either stop working completely or will transmit but at a very strange baud rate. Example if set to 115200 I was seeing an actual baud of 142900, if anything was transmitted at all.
I was using BufferedSerial in my project.
I did not test UnbufferedSerial as I found the issue in the target's support files.
Target(s) affected by this defect ?
MIMXRT1050_EVK
Toolchain(s) (name and version) displaying this defect ?
ARM Compiler 6.16
What version of Mbed-os are you using (tag or sha) ?
mbed OS 6.15.1
The bug still exists in the github master
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
MBed studio 1.4.4
ARMC 6.16
How is this defect reproduced ?
I was working with lpuart3. The default console is running on lpuart1 with default settings apart from baud rate with no issues.
#define CONTROL_SERIAL_TX GPIO_AD_B1_06
#define CONTROL_SERIAL_RX GPIO_AD_B1_07
...
BufferedSerial *serialPort;
char buf[64];
serialPort = new BufferedSerial(CONTROL_SERIAL_TX, CONTROL_SERIAL_RX);
serialPort->set_blocking(true);
serialPort->set_baud(115200);
serialPort->set_format(8, BufferedSerial::None, 1);
sprintf(buf, "This is a test message");
serialPort->write(buf, strlen(buf));
The bug is in:
mbed-os\targets\TARGET_NXP\TARGET_MCUXpresso_MCUS\TARGET_MIMXRT1050\TARGET_EVK\serial_api.c
void serial_format(serial_t *obj, int data_bits, SerialParity parity, int stop_bits)
{
LPUART_Type *base = uart_addrs[obj->index];
uint8_t temp;
/* Set bit count and parity mode. */
temp = base->CTRL & ~(LPUART_CTRL_PE_MASK | LPUART_CTRL_PT_MASK | LPUART_CTRL_M_MASK);
...
base->CTRL = temp;
All the control registers in the IMXRT1050 are 32bit. base->CTRL has a default value of 0x002c0000.
temp is a uint8_t so when you read in base->CTRL it gets truncated to 0x00.
When it is written back to base->CTRL the lpuart stops working.
Changing temp to a uint32_t resolves the bug