RTOS/TMDSIDK437X: AM4379 TI RTOS UART1 activation

Korkut Duvan

Part Number: TMDSIDK437X
Other Parts Discussed in Thread: AM4379, TEST

Tool/software: TI-RTOS

Hi there,

We require to add UART1 to our IDK_AM4379 development board with TI RTOS of the processor sdk rtos_am437x_5.00_00_15 installed on it.

We are trying the "uart_polling_test.c" file on the pdk_am437x_1_0_13.

Unfortunately, this example is not prepared for our board, hence the padConfig_prcmEnable() code does not include register write details for Uart1 on our mcu.

Can anyone let us know how to reach the proper values? Or does anyone have a suggestion to use another uart code example to adapt in our project for additional uart peripheral?

And we will appreciate a lot, if there exists kinda step by step documentation on how to properly turn on the additional peripheral?

Thanks in advance,

Warmest regards,

Korkut.

over 3 years ago

0 Rahul Prabhu over 3 years ago

TI__Guru* 96430 points

Korkut,

Please refer to the application notes below. They were created for AM335x platform but also apply to AM437x :

Other similar customization related to board have been described here:

4628.AM335x_AMIC110_Board_Porting_using_PRSDK.pdf

Hope this helps.

Regards,

Rahul

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Hello Rahul,

Thank you for the detailed documentation.

It really helped, now our IDK's UART1 is working very well with 115.200 baud.

Increasing the baud rate to 921.600 is somehow resisting to our trials. Seems like a clocking issue.

The serial capture program shows BREAK and ERROR values, when we increase the BR to 921.600.

As we return back to 115.200, communication is again all OK.

Do you have any idea why the UART1 faces such issues with increased data rates?

Is it an issue specific to UART1 or do you have any suggestions for the resolution?

Thanks in advance for your time,

Regards,

Korkut.

0 Rahul Prabhu over 3 years ago in reply to Korkut Duvan

TI__Guru* 96430 points

Korkut,

I am really glad to know that you are able to make progress on this UART issue. Could you please indicate how are you modifying the baud rate with this setup ? Are you setting the UART Driver baud rate to that value.

You may want to take a look at my suggestions here with the UART driver in terms of how the driver configures the divisor for the clock to set certain baud rate.
e2e.ti.com/.../697553

We had found an issue related to the clocking last year which we have fixed by allowing users to set the operating mode so make sure that you set the baud rate to 921600 and pick the correct operating mode to get to the desired baud rate.

Regards,
Rahul

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Yes, exactly. The issue in the link is almost the same.
Everything is fine with 115.200 and complete frame errors when upgraded to 921.600.

We initiliaze UART1 right after the board initialization config in the main.c file.

Here, below, I attach the code segment in the UART_task in RTOS, where the UART1 BR is changed in app.c file :

PRCMModuleEnable(CHIPDB_MOD_ID_UART, 1U, 0U); // UART1 clock enable
PINMUXModuleConfig(CHIPDB_MOD_ID_UART, 1U, NULL); // UART 01 pinmux; CHIPDB_MOD_ID_UART=42U;

// UART parameters structure polled mode
const UART_Params user_params = {
UART_MODE_BLOCKING, // readMode
UART_MODE_BLOCKING, // writeMode
0U, // readTimeout
0U, // writeTimeout
NULL, // readCallback
NULL, // writeCallback
UART_RETURN_NEWLINE, // readReturnMode
UART_DATA_TEXT, // readDataMode
UART_DATA_TEXT, // writeDataMode
UART_ECHO_ON, // readEcho
115200, // baudRate !!!************************** We change this value to 921600
UART_LEN_8, // dataLength
UART_STOP_ONE, // stopBits
UART_PAR_NONE // parityType
};

int32_t count;
char input = '\n';
char buffPointer[1000];
char echoPrompt[] = "Konum:\n";
char echoPrompt1[] = "Degerler:\n";

UART_Handle dkUart1;

dkUart1=UART_open(1, &user_params);

Task_sleep(100); // Diger uygulamalar toparlayana kadar sure ver...

UART_write(dkUart1,echoPrompt,sizeof(echoPrompt));

while(1) {
count=UART_readPolling(dkUart1,buffPointer,1000);
UART_write(dkUart1,&input,1U);
UART_write(dkUart1,echoPrompt1,sizeof(echoPrompt1));
UART_write(dkUart1,buffPointer,count);
UART_write(dkUart1,echoPrompt,sizeof(echoPrompt));

Task_sleep(500);
}

We change the baud rate value in the user_params.
We expect RTOS to make required settings considering the changed parameter.

Reading your comments in the link carefully, it seems we have to change also the oversampling value.
We can change the two yellow highlighted modifications.

We will try and let you know.

Thank you.

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Thank you Rahul.

You again pointed us the correct path :)

Now also 921.600 showed some proof of life, we are receiving correct bytes from the slave module, except some missing ones of the communication.

For example, the slave module is sending 4 bytes of header information, we receive byte1, byte2 and byte4 correctly with expected values.

Unfortunately byte3 is missing.

When we connect to the slave with PC through an FTDI connection, all data flow is proper.

Therefore it looks like we still need to configure the sequencing of receiver side of UART1.

We would appreciate if you can comment further.

Regards,
Korkut.

0 Rahul Prabhu over 3 years ago in reply to Korkut Duvan

TI__Guru* 96430 points

Korkut,

Do you have any information to share about the third missing byte. Can you indicate if that byte is 0xFF ? If the third byte being sent is 0xFF then you are likely running into this issue.

https://e2e.ti.com/support/processors/f/791/t/721812?CCS-TMDSICE3359-UART-doesn-t-receive-0xFF

The bug PRSDK-4529 reported in the E2E was resolved in the Processor SDK RTOS v5.02 that we released using the following to commits:

http://git.ti.com/keystone-rtos/uart-lld/commit/fc99ad761cddfbb88dbb72fdd64d0b20594004e5

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

I started to believe that you have some mystic powers of seeing the future :)

Absolutely.
The missing byte is an exact shy 0xFF, hiding behind the screen but not showing off.

Let us see if we can encourage them, applying the above.

Thank you.

0 Rahul Prabhu over 3 years ago in reply to Korkut Duvan

TI__Guru* 96430 points

Korkut,

We have a vibrant and diverse developer community using our Sitara product lines so we do see many such issues reported and fixed. Having worked on some of these myself, I have seen these issues first hand so it helps spotting patterns based on symptoms that you are reporting.

Let us know if this issue is not resolved with that fix.

Regards,

Rahul

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Rahul,

I think we need to push the UART peripheral a bit more .

As an improvement with the latest modification of P_SDK v5.2, we can read the 0xFF on third byte.
The first and second bytes of header are still correct.

However, this time, the fourth byte is disoriented. It should be a 0x55, now it is visualized as 0xD5 on screen.

Inside the message there are some reserved bytes, they should be a sequence of 0x00's, but they are not.

Instead, there is a sequence of 0x80's, which means an additional logic HIGH bit to the MSB of every byte of information.

This came with the modification. Previously we could not read the 0xFFs, but the reserved bytes were all 0x00's.

Plus 4th byte of header has the same characteristics, as it is evolved to a 0xD5 instead of 0x55.

Again an additional logic 1 to the MSB of the byte.

And the serial capture program is showing frame errors for all incoming messages.

I have tried also modifying UART13X_OPER_MODE manually as before; even though, the issue persists.

What do you think? Where is the additional bit coming from?

Let me know,

Thank you.

0 Rahul Prabhu over 3 years ago in reply to Korkut Duvan

TI__Guru* 96430 points

Korkut,

Can you please confirm that you have the following setting with the driver:

uartParams.readDataMode = UART_DATA_BINARY; // do not handle CRLF Default UART_DATA_TEXT
uartParams.writeDataMode = UART_DATA_BINARY; // do not handle CRLF
uartParams.readReturnMode = UART_RETURN_FULL;

Also, have you applied both the UART LLD and CSL patch for the issue?

I am trying to understand if the test case of the fix in the PRSDK 5.02 has accounted for 0x FF input and checked to see if other inputs are not affected. If you confirm that you have applied the fix correctly and the driver is configured as above then I need to check if this is a new issue.

Regards
Rahul

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Hi Rahul,

Let me tell you how I did apply the above:

1- As I am using the UART_polling_test.c file as reference, I have tried UART_DATA_BINARY for read and write data mode, and also UART_RETURN_FULL at the same time changing the values in the user_params in my app.c file with which I initialize and open myUART1. The result is the same as an additional logic high on MSB of all following bytes either with UART_DATA_BINARY or even with UART_DATA_TEXT.
But strangely the first three bytes of the header are always correct throughout whole communication. Frame error seems to start after the 0xFF.

2- Assuming that PRSDK 5.02 has the patches already applied on, I have deleted the previous prsdk, pdk and other components, and installed every component coming with PRSDK 5.02 on C:/ti folder. And restarting the CCS v8 introduced the newly installed components, and selected from products tab, the am437x PDK tick with latest 1.0.13 and SYS/BIOS 6.73.1.01 and XDC tools version as 3.50.8.24. All other older components are deleted from the C:/ti folder.
Therefore the project sees only the newest version components that came with PRSDK 5.02.
As my first assumption was that the components came all with the new modification, I did not change anything for UART LLD and CSL portions. When I checked the UART_V1.c for UART13X_OPER_MODE, I saw that part was already modified. I even tried to modify that part as UART13X_OPER_MODE however the result was the same.

One point that I doubt is that I did not reimport the rtos_temp_app from the new PRSDK, instead I modified the old one with changing the installed PDK, SYS/BIOS, XDC and etc components. Not sure if it may be the reason.

Let me know if there are any further modification steps to apply.

Thank you,
Korkut.

0 Korkut Duvan over 3 years ago in reply to Korkut Duvan

Prodigy 170 points

Rahul,

Additional info:

I have another AM4379 development board, that is a GP EVM with LCD screen.

I have imported a fresh new RTOS that came with the PRSDK v5.02; unfortunately, the result is the same.
Hence, it seems to be a signal that this is a bug to be resolved that came with the new PRSDK.

If you have a chance to prepare a test setup of AM4379 processor, the faulty operation of UART peripheral is apparent.

And if you can point me the correct direction (as always:)), I can also try to trace the source of that additional bit.

Should I concentrate on UART_v1.c file? CSL or DRV folder or both?

Let me know,
Thank you.

0 Rahul Prabhu over 3 years ago in reply to Korkut Duvan

TI__Guru* 96430 points

I did a quick test with loopback enabled, I used UART_write to send data 0x55, 0xaa, 0x7f, 0xff, and UART_read() received all the data correctly. Please check with the customer how they produced the problem. You may use the existing UART_test_read_verify() unit test case for loopback test.

Regards,
Rahul

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Rahul,

The customer deleted all previous versions, re-created a new software environment from the latest PRSDK, plus reinstalled the CCS v8.

The communication is brilliant at 115.200 BR. All bytes correct, no receiver frame errors. Crystal clear throughout whole transfer.

When they switch to 921.600, complete frame errors are observed. Yet the first three bytes are always correct. Following ones are disoriented.

The only change they do is the Baud Rate(only that single parameter), and they lose complete communication afterwards.

Even they receive the first three bytes correctly all the time.
But they need a 40-50 bytes received at a time and echoed to an outer terminal with 921K baud.

Can you point out or forward me your test code for 921.600? So that we can try fastly to see if it works for them.

Thank you.

0 Korkut Duvan over 3 years ago in reply to Korkut Duvan

Prodigy 170 points

Hello Rahul,

The issue is resolved. Now the communication is crystal-clear even at 921.600 baud.

I did not enable the loopback, and left it disabled.

The source of the problem was the HW_attrs definition in the "UART_soc.c" file.

The oversampling was the cause. Changing it in the hardware attributions for UART1 cleaned the table completely.

This means the RTOS is not yet autonomous for baud rate selection, even with the latest PRSDK (v5.02).

So if the developer changes the baud rate, he has to check and make manual settings to have the added peripheral stand up.

It would be great if the RTOS could have assigned the proper oversampling value for the baudrate.

Because it seems anyone who runs like 921Kbaud will face this issue. At least for higher data rates.

Hope this will be added in the next versions of PRSDKs.

Thanks for your great support throughout.

Warmest regards,
Korkut.

0 Rahul Prabhu over 3 years ago in reply to Korkut Duvan

TI__Guru* 96430 points

Korkut,

Glad to know that the customer was able to resolve this. Yes, the Oversampling factor is now part of HWattr to allow customers the flexibility to change that based on baud rates and clocking required.

If possible please provide some back ground on why the 921600 baud rate is preferred in the setup. Are there any encoders, safety interfaces or interface cards that need these higher baud rate requirements.

Regards,
Rahul

0 Korkut Duvan over 3 years ago in reply to Rahul Prabhu

Prodigy 170 points

Oh, sure.

There is an interface board on client side with a default baud rate of 921K.
The data rate was the bottleneck with a message length of nearly 50 bytes.
Since, the client side interface board is fixed, there were not many choices.

At least for the startup :)

Processors

Processors forum

RTOS/TMDSIDK437X: AM4379 TI RTOS UART1 activation