UART_HAL_SetRxDataRegFullIntCmd

cancel
Showing results for 
Search instead for 
Did you mean: 

UART_HAL_SetRxDataRegFullIntCmd

1,278 Views
tim
Contributor I

I am not seeing anything from the UART with this code in fsl_uart_hal.h:

 

/*!

* @brief Disables the rx_data_register_full_interrupt.

*

* @param   baseAddr UART module base address.

* @param   enable   true: enable, false: disable.

*/

static inline void UART_HAL_SetRxDataRegFullIntCmd(uint32_t baseAddr, bool enable)

{

    /* receiver interrupt enable for receiver data register full (RDRF)*/

    BW_UART_C2_RIE(baseAddr, (uint8_t)enable); 

}

 

which is called with:

 

UART_HAL_SetRxDataRegFullIntCmd(baseAddr, true);

 

 

from fsl_uart_driver.c in the SDK.

 

I am able to output data but nothings coming in.  Any ideas?

 

Thanks,

 

Tim

FRDM-K64F

IAR EWIDE

I-jet

Labels (1)
0 Kudos
8 Replies

628 Views
tim
Contributor I

I suppose I should have asked this question as follows:

Why isn't UART_DRV_ReceiveDataBlocking from the SDK working.  I am able to send data out with UART_DRV_SendDataBlocking from the SDK without issue so I am assuming I have everything initialized but maybe that is a bad assumption.  I am running this on a FRDM-K64F and using IAR Embedded Workbench IDE with an i-jet debugger.  I can Live Watch UART0_D, along with the other UART0 registers and I can see my data getting to there, it just isn't coming out of the SDK.

When I call this function:

UART_DRV_ReceiveDataBlocking(uint32_t instance, uint8_t * rxBuff, uint32_t rxSize, uint32_t timeout)

I would expect to see at my data in rxBuff, but the debugger isn't even seeing it.  Anyone from Freescale care to offer an opinion?

Thanks very much!

Tim

0 Kudos

628 Views
DavidS
NXP Employee
NXP Employee

Hi Tim,

Not sure why you are not seeing the Rx side of the UART working.

I just did a test using KDS1.1.1 with KSDK1.0.0 and was able to make it work.

My test looks like:

    while(1) {

    GPIO_DRV_TogglePinOutput(kGpioLED2);

    return_status = UART_DRV_SendData(BOARD_DEBUG_UART_INSTANCE, myTextString2, sizeof(myTextString2));

    for(i=0;i<10000000;i++) { //DES ~2second delay loop

    __NOP();

    }

    loop_count++;

    if(loop_count > 4)

    break;

    }

    return_status = UART_DRV_ReceiveDataBlocking(BOARD_DEBUG_UART_INSTANCE,

                                               &myRxTextString1,

                                               4,          //DES hard coded that I want to receive 4 characters before un-blocking.

                                               OSA_WAIT_FOREVER);

    if(return_status != kStatus_UART_Success)

    __BKPT(4); //DES break if error

    myRxTextString1[4] = 0; //DES NULL terminate string

  return_status = UART_DRV_SendData(BOARD_DEBUG_UART_INSTANCE, myRxTextString1, sizeof(myRxTextString1));

My Terminal output was:

This is the hello world of kds at 115200 baud

This is the hello world of kds at 115200 baud

This is the hello world of kds at 115200 baud

This is the hello world of kds at 115200 baud

This is the hello world of kds at 115200 baud

1234

Let me know if you get it working.  If not I will try IAR tomorrow.

Regards,

David

628 Views
tim
Contributor I

So obviously there is something not getting initialized correctly.  Thanks David for the reply.  I see the "Hello World" demo can be configure to use UART_DRV_ReceiveDataBlocking, so I will spend a bit of time today tracing it and see what isn't getting set or not set.

Thanks again,

Tim

0 Kudos

628 Views
DavidS
NXP Employee
NXP Employee

Hi Tim,

Please do let us know the results.

Had you used the "OSA_WAIT_FOREVER" parameter for the timeout?

Regards,

David

0 Kudos

628 Views
tim
Contributor I

Hi David,

I am using a timeout of 1.  Here is the call:

     UART_DRV_ReceiveDataBlocking(BOARD_DEBUG_UART_INSTANCE, &ch, 1, 1);

IAR EW allows me to step into this function and I can see data in UART0_D but it doesn't get returned.  When I take out breakpoints and let it run free through these functions, it won't return.  When I stop it, I end up here:

pastedImage_0.png

When stepping through it, I can't see anything wrong, except for the lack of the return.

Thanks,

Tim

0 Kudos

628 Views
DavidS
NXP Employee
NXP Employee

Hi Tim,

I am looking at the IAR hello_world in KSDK1.0.0 and see the same issue.

I am looking at the KDS hello_world in KSDK1.0.0. and see the same issue.

If I use File->New->Kinetis Design Studio Project and use PE, I am not having the issue.

In short the LPTMR appears to not be setup which causes issue when configuring the timeout to anything but "OSA_WAIT_FOREVER".

I will continue to look to find the switch to turn on the LPTMR and get back to you.

I just wanted to do a quick update.

Regards,

David

0 Kudos

628 Views
tim
Contributor I

Thanks David,

Full disclosure, I am working to port shell_test from the beta into the release KSDK1.0.0.  I think there are issues with IAR in debugging, as it isn't acting the way I would expect so I am working with them to see what they say.

I tried using OSA_WAIT_FOREVER but no joy and EW isn't helping me figure out why.  I am not familiar with the other IDE's so I am not going there.

I will keep you posted on what I figure out.

Thanks for your help,

Tim

0 Kudos

628 Views
DavidS
NXP Employee
NXP Employee

Hi Tim,

My assumption was correct.  The hello_world project in KSDK1.0.0 did not have the LPTMR enabled so any value other than OSA_WAIT_FOREVER for timeout cause issue.

Attached is my modified hello_world.c program.  I basically grabbed code from the lptmr_demo and set LPTIMER up into non-interrupt mode so it run as a free counting timer and now works when a timeout value is used.

Regards,

David 

0 Kudos