AM335x Bad baudrate on all serial ports (unwanted changes at run-time)

Hi Steve,

Do you mean that your baudrate is randomly changing in an unpredictable way?

Please provide more information about your hardware and software. What board are you using - one of the TI boards or a custom one? What software are you using and which version?

Best regards,
Miroslav

Hi,

 It's a custom board with a AM3354 rev 0 cpu at 720MHz running windows Embedded Compact 7, we are using the TI serial driver from the SDK.

 UART0 is for debugging and openend (only once) when booting windows, setup (only there) to 115.2000 baud and sending data out.

 UART3 is frequently openend, setup to 115.200 baud, data transfert and closed again.

 

 At some point the baudrate has changed (ex. 142.000 baud) on these two UARTs and stays bad even if UART3 is setup again to 115.000 baud.

 I don't think it's the baudrate deviders because both UARTs changed and stay bad even if UARD3 is reconfigered to 115.2000.

This E2E post in the WinCE forum might be helpful.

http://e2e.ti.com/support/embedded/wince/f/353/p/181998/658537.aspx#658537

Please review the questions at the beginning and then follow the debug steps to see if you are experiencing a similar issue. 

This post may also prove helpful as you try to debug the UARTs

http://e2e.ti.com/support/embedded/wince/f/353/t/258270.aspx

After more debuging on a bad board I found not only all the baudrates where bad but also MMC0 and MMC1 had the same increase in clock speed.

MMC0 and MMC1 clock was running at 30MHz instead of 24MHz, USB is not working any more (probably also bad clock)

So the problem is not in the baudrates but in the Peripheral PLL !

Is there any reason for the Peripheral PLL to increase the clock frequency ?

Is it normal for a Windows Compact Embedded (7.0) application (so not a driver) to be able to read / write the interal regsiters of the CPU ?

How can we protect this region from the application ?

Hello Steve,

Assuming your external clock input does not change, I assume the PLL configuration is accidentally changed by software.

I don't know how WinCE uses the MMU, but I assume those registers should not be writable from user space.

Can you please check the following registers for the peripheral PLL configuration:

CM_CLKMODE_DPLL_PER (0x44E0048C) -> 0x7 (PLL lock)

CM_CLKSEL_DPLL_PER (0x44E0049C)  -> 0x4 03C0 17 (SD div, multiplier, divider)

CM_DIV_M2_DPLL_PER (0x44E004AC) -> 0x2 8 5 (clockout, status, M2 divider)

The following registers for the core PLL should be 0:

0x44E0520, 0x44E052C, 0x44E0530.

Regards,

Lo

Extra info :

 Reinnitialising the peripheral PLL again (see datasheet how to change the divider) will also get you back on the correct baudrate.

 Only problem is how to know if the baudrate has switched.

Hello all,

we are having the same problem on a custom board with Wince7 but on UART3.

the baud is set to 9600 and all is ok for a while (UART tx signal signal monitored with scope) but sometimes, randomly, the baud switches to something similar to 4100 (measured with scope we don't know the read baud).

Do you have any update on this post?

Claudio

The cause is an unstabel Peripheral PLL, you should contact TI for this.

They can give you more info on a possible solution but it's not yet public on the website.

Thanks for the prompt reply.

Is it something related to this post

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/268225/1011560.aspx#1011560

and Advisory 1.0.30 on silicon errata?

I've found it browsing the forum for pll problems.

Ciao Claudio

Yes that is the one.

Regards,

Steve

Thanks again for the prompt relpy,

did you implemented the changes and does the fix solved the problem for you?

Ciao Claudio

Yes we added the patch and after only a short test (needed a quick fix for the field)  we didn't get the error any more.

It's difficult to tell for us if this solves it completely because we also have implemented a software solution to reinitialize the PLL if we receive bad characters on the serial port.

It didn't make it worse so why not implement it.

Yesterday we made some additional test checking some of the uarts at the same time. The strange point we noted is that when the problem fires not all the Uarts are affected. I.e. the uart2 and uart1 changes baud but uart3 does not. This seems not in line with the PLL problem cause all uarts share the same PLL. So if the PLL jumps to different frequency all uarts should be affected, is this true or am I missing some point? Moreover if we close the port and reopen with the same baud after the problem fires nothing changes and the problem presist, but if we change the baud the port correclty works on the new baud and if we switch back to the original baud all works fine. This still seems to be incompatible with PLL problems, am I correct? Thanks for your kind help. Ciao Claudio

If resetting the baudrate solves your problem and it doesn't happen on alle UARTs than you don't have th PLL issue.

Could it be you have some power down mode enabled on your device ?

D3 or D4 state would porbable stop the clocks ?

Regards,

Steve