LCDK OMAP-L138 UART0 problem

Alexander Romanovskiy

Other Parts Discussed in Thread: OMAP-L138

Hello,
I'm working with LCDK OMAP-L138 rev.a6. I'm using bsl v2.3 at ccs 5.4.
I try to transmit information by UART with tests from bsl.
I can do it by UART2 using usb cable.

But couldn't do it by UART0 and 1.
BSL test passed success. But I don't recieve any information on oscilloscope screen.
I take ground from 35 pin and try to recive data from 29 pin UART0_TX or 19 pin UART1_TXD of of J15.

After reading this:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/200681.aspx?pi209567=2
I shorted R206 and R209.Removed only R208, because there was no R205.
After this I recieved data from UART1 on oscilloscope screen.

But removing R172, R173, R277 and shorted R218 and R219 didn't repair UART0.

Also I notice some interesting thing:
1. At bsl Test.
For example for UART2 we write 0x00440000 at PINMUX0,
But for UART0 we write 0x00002222 at PINMUX3. Why not 0x22220000?
I tried to write and 0x00002222 and 0x22220000 but it doesn't help too.

2.why does 29 and 19 pins has different names UART1_TXD and UART0_TX?
Is letter d important?

Regards,
Alexander.

over 11 years ago

0 Antony Samsunil over 11 years ago

TI__Expert 4760 points

Hi Alexander,

Make sure the PINMUX3 value should not supersede by some other value from other functions, check the final value in the CCS view register option.

Check the auto Flow control options are enabled? In such cases RTS and CTS will come into picture.

Check you’ve set the baud rate properly?

Check the internal loop back control is enabled?

Check the Line status register (LSR) for any errors? Concerning the status of the data transfer

The UART1_TXD and UART0_TX is just the net name that won’t be an issue.

Regards

Antony

0 Alexander Romanovskiy over 11 years ago in reply to Antony Samsunil

Intellectual 735 points

CCS shows 0x8888 2222 value at PIMUX3 and 0x60 value at LSR in non-FIFO mode.

Baud rate set to 115200.

I can't find anythig about auto Flow control options and internal loop back control.

Where can I check this controls?

There is one test to UARTs. I just change value of debug port (0,1,2). 1 and 2 work fine, but no 0.

Regards,

Alexander.

0 Alexander Romanovskiy over 11 years ago in reply to Alexander Romanovskiy

Intellectual 735 points

With memory browser help I found some things that I don't understand.

There is a function in test, that writes pinmux registers:

void EVMOMAPL138_pinmuxConfig(uint32_t in_reg, uint32_t in_mask, uint32_t in_val)
{
   // unlock the system config registers.
   SYSCONFIG->KICKR[0] = KICK0R_UNLOCK;
   SYSCONFIG->KICKR[1] = KICK1R_UNLOCK;
   
   // make sure the pinmux register is cleared for the mask bits before
   // setting the value.
   CLRBIT(SYSCONFIG->PINMUX[in_reg], in_mask);
   SETBIT(SYSCONFIG->PINMUX[in_reg], in_val);
   
   // lock the system config registers.
   SYSCONFIG->KICKR[0] = KICK0R_LOCK;
   SYSCONFIG->KICKR[1] = KICK1R_LOCK;
}

I read 0x0x8888 2222 value from PINMUX[3] register. Than I changed in_val value in function from 0x00002222 to 0x2222000. Started test. And read PINMUX[3] again. There was 0x0x8888 2222 again.

I changed debug port to UART1, changed in_val value to 0, not to write TXD and RXD. And started test. I saw recieved data on oscilloscope.

I understood that tihis function don't write any values to pinmux registers.

I read KICK0R and KICK1R and didn't find unlock values. There was 0.

Then I tried to write unlock values through memory browser, but it couldn't do it.

And at the end I tried to write 0x22220000 value to PINMUX[3] register. It was written to my surprise.

I started test and saw data on oscilloscope.

So problem with UART0 I resolved. Can you tell me why does this function can't unlock Pinmux registers?

Regards,

Alexander.

0 Antony Samsunil over 11 years ago in reply to Alexander Romanovskiy

TI__Expert 4760 points

Hi Alexander,

Good that you’ve resolved this issue.

Basically this function did the protection mechanism to prevent any spurious writes to the PINMUX register.

To allow writing to the registers in the module, it is required to “unlock” the registers by writing to two memory-mapped registers in the SYSCFG module, Kick0 and Kick1, with exact data values. Once these values are written, then all the registers in the SYSCFG module that are writeable can be written to.

Please refer the TRM SPRUH77A page no 223 for more details

Note: The kick registers are disabled in silicon revision 2 and later. The SYSCFG registers are always unlocked and writes to the kick registers have no functional effect.

Regards

Antony

--------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

0 Alexander Romanovskiy over 11 years ago in reply to Antony Samsunil

Intellectual 735 points

oh, thank you. I didn't notice this moment. I've got 2 revision.

Processors

Processors forum

LCDK OMAP-L138 UART0 problem