LPC11U68 CTS

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

LPC11U68 CTS

2,015件の閲覧回数
toddwade
Contributor II

I'm using a 48-pin LPC11U68, making use of USART0.  I'm having trouble getting *any* value for the CTS input. I'm using Port 0, pin 7 in the IOCON set up.  

I've tried enabling auto-cts, as well as setting up modem status interrupts, with the CTS change-of-state interrupt enabled too.  

To date I can see nothing that correlates to the CTS input.  When I read the CTS bit in the modem status register, it never reflects the current state of the CTS input, nor does the change-of-state ever move.

My setup:

Chip_IOCON_PinMuxSet(LPC_IOCON, 07, (IOCON_FUNC1 | IOCON_MODE_PULLDOWN | IOCON_DIGMODE_EN));

Chip_UART0_SetModemControl(LPC_USART0, UART0_MCR_AUTO_CTS_EN);  <-- confirmed in MCR

Chip_UART0_IntEnable(LPC_USART0, (UART0_IER_RBRINT | UART0_IER_RLSINT | UART0_IER_MSINT | UART0_IER_CTSINT)); <-- Confirmed in register

In my ISR, I never see a change of CTS state, even though the input definitely has a changing input.

Auto-CTS is not working, in that TX continues regardless of the CTS input from the receiving device.

I saw another post about this very issue, and no one responded.  Is this a known problem with this port, or is there some secret sequence to configure it for correct operation?

Thanks
ラベル(1)
タグ(1)
0 件の賞賛
返信
8 返答(返信)

1,417件の閲覧回数
jeremyzhou
NXP Employee
NXP Employee

Hi Todd Wade,

Thank you for your interest in NXP Semiconductor products and the opportunity to serve you.

I was wondering if you can share the demo, then I can replicate the issue on my site.

It's good for me to figure out the root cause of the issue.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 件の賞賛
返信

1,417件の閲覧回数
toddwade
Contributor II

Here is my test code. 

LPC11U68, 48-pin part.  CTS on PORT 0, PIN 7.

This will just keep transmitting regardless of the CTS input.  Also, notice that I enabled modem-status interrupts.  It doesn't enter the ISR when a change of CTS input occurs either...

...

RINGBUFF_T  TSTtxring; 
uint8_t     TSTtxbuff[256];
RINGBUFF_T  TSTrxring; 
uint8_t     TSTrxbuff[256];

#ifdef WATCH_INPUT
static uint32_t count = 0;
#endif

// USART0 ISR
void UART0_IRQHandler(void)
{
    Chip_UART0_IRQRBHandler(LPC_USART0, &TSTrxring, &TSTtxring);
}

// Test function for the serial port CTS issuevoid testSerial(void)
{
    unsigned char                buf[1024];      

    // USART 0 Tx/Rx
    Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 18, (IOCON_FUNC1 | IOCON_MODE_INACT | IOCON_DIGMODE_EN));
    Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 19, (IOCON_FUNC1 | IOCON_MODE_INACT | IOCON_DIGMODE_EN));

    // USART 0 CTS/RTS
    Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 17, (IOCON_FUNC1 | IOCON_MODE_INACT | IOCON_DIGMODE_EN));
    Chip_IOCON_PinMuxSet(LPC_IOCON, 07, (IOCON_FUNC1 | IOCON_MODE_PULLDOWN | IOCON_DIGMODE_EN));      

    /* Setup UART for 9600 N,8,1 */
    Chip_UART0_Init(LPC_USART0);
    Chip_UART0_SetModemControl(LPC_USART0, UART0_MCR_AUTO_CTS_EN);
    Chip_UART0_SetBaud(LPC_USART0, 9600);
    Chip_UART0_ConfigData(LPC_USART0, (UART0_LCR_WLEN8 | UART0_LCR_SBS_1BIT));
    Chip_UART0_SetupFIFOS(LPC_USART0, (UART0_FCR_FIFO_EN | UART0_FCR_TRG_LEV2));
    Chip_UART0_TXEnable(LPC_USART0);
    
    /* 
       Before using the ring buffers, 
       initialize them using the ring
       buffer init function
    */
    RingBuffer_Init(&TSTrxring, TSTrxbuff, 1, 256);
    RingBuffer_Init(&TSTtxring, TSTtxbuff, 1, 256);

    /* Enable receive data and line status interrupt */
    Chip_UART0_IntEnable(LPC_USART0, (UART0_IER_RBRINT | UART0_IER_RLSINT | UART0_IER_MSINT));      

    /* Enable UART 0 interrupt */
    NVIC_EnableIRQ(USART0_IRQn);

    // Set some default characters into our buffer
    memset(buf, 0x56, sizeof(buf));      

    /*
    ** Loop forever transmitting characters.
    ** When CTS goes HI, the output should stop??
    **
    */
    while (1)     
    {
        Chip_UART0_SendRB(LPC_USART0, &TSTtxring, (const void *)buf, sizeof(buf));

       // Use this to prove I'm getting input on the pin.      
       #if (WATCH_INPUT)
       if (Chip_GPIO_ReadPortBit(LPC_GPIO, 0, 7))
       {
            count++;
       }
       #endif
    }
}

void main(void)
{
   testSerial();
}

Let me know if you need anything else.

Thanks!

1,417件の閲覧回数
jeremyzhou
NXP Employee
NXP Employee

Hi Todd Wade,

Did you ever use the oscilloscope or logic analyzer to sample the signals of communication?

If yes, I was wondering if you can share the sampled signals.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 件の賞賛
返信

1,417件の閲覧回数
toddwade
Contributor II

Ping,

Do you have any update on this issue?  

Todd

0 件の賞賛
返信

1,417件の閲覧回数
jeremyzhou
NXP Employee
NXP Employee

Hi Todd Wade,

Please check attachment and refer to it for details.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 件の賞賛
返信

1,417件の閲覧回数
toddwade
Contributor II

I have looked at it on a scope, but I don't have a capture.  

When I run the sample code above, I watch the TX data coming from the processor and then assert the CTS by hand (pull the pin HI).  Whether I drive the CTS input HI or LO, data continues to come out of TX.  Also, I never see a change of state in the modem status register, nor does the CTS value change in the MSR either.

I verified that the signal is reaching the processor through the code residing between the WATCH_INPUT #define in my test code, so I absolutely know the signal is present.  

1.  Have you tried this on a 11u68 in the same package?

2.  Do you see any similar behavior?

3.  Why does the processor show ZERO indication in the MSR of the state of the CTS input and why doesn't it show a change of state for that input?

4. Why is no modem status interrupt is generated?

5.  Since this was reported by someone else with identical issues, I have to conclude there may we'll be something to my issue.  I'm willing to admit I may not be configuring something correctly, but I cannot see what and no one has shown me what it would be.  At present I'm more inclined to think there's a problem with the part.  I'd be thrilled to be wrong.  The other person who reported this got no answer either.

i cannot change the design of the board, so if I can't get this resolved in the next few days I will have to work around it somehow and move on.   Frustrating.

0 件の賞賛
返信

1,417件の閲覧回数
jeremyzhou
NXP Employee
NXP Employee

Hi Todd Wade,

Have a look through the codes, I didn't find something wrong with them.

I'm still working on it now.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 件の賞賛
返信

1,417件の閲覧回数
toddwade
Contributor II

Hi Jeremy (or is it Ping?),

Thanks for your reply.

I'll need to extract the code I'm using into an example.  It's tightly woven into the product that is based on this processor.  You'll obviously also need some hardware that will generate a CTS when the LPC is generating serial data fast enough to cause it (or simulate CTS with a resistor to supply or some-such.  A high level indicates the target wants the CPU to hold off... (can't recall which sense of the signal is necessary) ).

I'll try to do that in the next few days.  My current work-around is to insert a fixed delay after every transmission from the LPC11U68, so the peripheral can keep up.  Clearly that's not ideal, but I needed to be able to move forward on my project.

Have you heard of any issues like I'm describing?  As I mentioned in my post, someone else had the very same issue with this processor but I saw that no one responded.  It was originally posted on the LPCWare community site and then moved here once the transition occurred.  Not sure if that individual ever got resolution to this.

Thanks again!

Todd

0 件の賞賛
返信