TINA/Spice/AM5728: UART baudrate issue

Colombo Carlo

Part Number: AM5728

Tool/software: TI-RTOS

HI everybody ,

I am on IDK , I am using Uart everything is fine @ 115200 baud . now I need 921600 , I set as code hereunder but both TX and RX speed are wrong ( it seems to be 996720[bps]. )

where am I wrong ?

here is the code

uartParams.parityType = uartParity;

// *** At this place we can also change baud-rate settings etc.!!! ***

uartParams.baudRate = 921600; // Change the baud-rate from default 115200 to something else

// *************************************************************************

// Open a UART instance with the given UART parameters and receive a handle.

// *************************************************************************

uart = UART_open(uartTestInstance, &uartParams);

if (uart == NULL)

thank you very much

regards

Carlo

over 5 years ago

0 Biser Gatchev-XID over 5 years ago

TI__Guru**** 393215 points

The RTOS team have been notified. They will respond here.

0 Rahul Prabhu over 5 years ago

TI__Guru** 114410 points

Carlo,

I think this is expected behavior with current implementation in our driver and a small modification to the source should be able to help the customer fix this issue. Let me try to explain how the baudrate is calculated to allow for customer to make the required modification.

The default module clock to UART as per the TRM is 48 MHz so when the user selects a specific baudrate, the UART driver calculates the module divider values to get to that baudrate using the following formula:

UART divider = Module clk /(overSamplingRate * baudrate)

The issue here is that current UART driver hard codes the oversampling factor to 16 hence the divider for baudrate of 921600 is being computed as

48000000/ (16 * 115200) = 3.255. since the Register value needs to be integer value, this gets set to 3 but due to the rounding the baudrate is about 8.33 % off the required baud rate so actual resulting baudrate from this divider would be ~1Mbps (48000000/(16*3)) that is why the customer is measuring 996720.

The UART module provides another level of flexibility where the Oversampling rate can be set to 13 instead of 16 and I believe that would be better suited for this baudrate. If the over sampling rate is set to 13 instead of 16. The divider value (48000000/13*921600) = 4.00464 is closer to an integer value and will result in a buadrate closer to the one that customer requires.

If over sampling rate is set to 13 and divider is set to 4 the resulting baudrate would be 48000000/(13*4) = 923076 bps which is less than <1 % error from the baudrate. to update the driver the following lines of code need to be updated in UART_open_v1 function in the UART_v1.c file:

/* Computing the Divisor Value for params.baudRate */
divisorValue = UARTDivisorValCompute(hwAttrs->frequency,
object->params.baudRate,
UART13x_OPER_MODE,
UART_MIR_OVERSAMPLING_RATE_42);

/* Enable UART */
UARTOperatingModeSelect(hwAttrs->baseAddr, UART13x_OPER_MODE);

I would also like to add a a note with the change the same oversampling rate will also be used to 115.2 Kbps but the baudrate error introduced by this may be small.

Regards,

Rahul

0 Andreas Halbe over 5 years ago in reply to Rahul Prabhu

Intellectual 455 points

Hello Rahul,

I re-build the UART Drivers via the following commands, after applying your proposed change,:

C:\ti\pdk_am57xx_1_0_9\packages\pdksetupenv.bat
C:\ti\pdk_am57xx_1_0_9\packages\gmake uart_clean
C:\ti\pdk_am57xx_1_0_9\packages\gmake uart

Afterwards I rebuild my project. Indeed the baud-rate can now be set to 921600 and the data is being identified e.g. by a terminal program as expected.

Please let me ask an additional question. Do you think that it makes sense that the driver function "UART_open_v1" pre-calculates the expected inaccuracy due to the different oversampling options in advance and chooses automatically the one with the lowest error? That would be very convenient for users.

Thanks a lot for the support,
Andreas

0 Rahul Prabhu over 5 years ago in reply to Andreas Halbe

TI__Guru** 114410 points

Andreas,

Thank you for confirming the fix and glad to know you have this setup working in your environment.

I agree with your comment/feedback that the driver open call needs to pre-calculate the expected inaccuracy and handle the oversampling rate so I have filed a feature request to have this implemented. You can use PRSDK-4105 for tracking this in the Processor SDK RTOS Release notes.

We also checked the u-boot and Linux implementations for UART driver and it appears uboot uses similar implementation as RTOS LLD driver but the Linux driver has a function to pick the oversampling rate that results in closest baudrate.

Regards,
Rahul

Processors

Processors forum

TINA/Spice/AM5728: UART baudrate issue