Problem mixing polling and interrupt ROM-based UART

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problem mixing polling and interrupt ROM-based UART

726 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by remcopoelstra on Fri Aug 29 08:27:34 MST 2014
Hi,

I'm mostly using the UART with the ROM drivers in interrupt mode. This works.
When I try to receive a buffer in polling mode then the code seems to crash. Pausing the code gives the following output in the debugger:
Thread [1] <main> (Suspended : Signal : SIGINT:Interrupt)
0x1fff1af4
0x1fff1bec
0x1fff1bec
So I assume it is stuck in an interrupt.
I've tried calling NVIC_DisableIRQ(UART0_IRQn); before using the polling mode, but it still gets stuck in the interrupt.
Is it possible to mix interrupt and polling mode?

UART setup code:
void UART0_IRQHandler(void)
{
LPC_UART_API->uart_isr(uartHandle);
}

void setupUART(void) {
uint32_t frg_mult;

Chip_Clock_SetUARTClockDiv(1);/* divided by 1 */

Chip_UART_Init(LPC_USART0);

/* 115.2KBPS, 8N1, ASYNC mode, no errors, clock filled in later */
UART_CONFIG_T cfg = {
0,/* U_PCLK frequency in Hz */
115200,/* Baud Rate in Hz */
1,/* 8N1 */
0,/* Asynchronous Mode */
NO_ERR_EN/* Enable No Errors */
};

/* Setup the UART handle */
uartHandle = LPC_UART_API->uart_setup((uint32_t) LPC_USART0, (uint8_t *) &uartHandleMEM);

cfg.sys_clk_in_hz = Chip_Clock_GetSystemClockRate();

/* Initialize the UART with the configuration parameters */
frg_mult = LPC_UART_API->uart_init(uartHandle, &cfg);
if (frg_mult) {
Chip_SYSCTL_SetUSARTFRGDivider(0xFF);/* value 0xFF should be always used */
Chip_SYSCTL_SetUSARTFRGMultiplier(frg_mult);
}
}


Using the interrupt mode:
/* Enable the IRQ for the UART */
NVIC_EnableIRQ(UART0_IRQn);

_param.buffer = (uint8_t *) receive_buffer;
_param.size = length;

_param.transfer_mode = RX_MODE_LF_RECVD;
_param.driver_mode = DRIVER_MODE_INTERRUPT;

/* Setup the receive callback, this will get called when the
   transfer is complete */
_param.callback_func_pt = callback;

/* Receive the data */
LPC_UART_API->uart_get_line(uartHandle, &_param);


_param is a global variable.

Using polling mode:
UART_PARAM_T param;

/* Enable the IRQ for the UART */
NVIC_DisableIRQ(UART0_IRQn);

param.buffer = (uint8_t *) receive_buffer;
param.size = length;

param.transfer_mode = RX_MODE_BUF_FULL;
param.driver_mode = DRIVER_MODE_POLLING;

/* Receive the data */
LPC_UART_API->uart_get_line(uartHandle, &param);


Any insights would be highly appreciated.

Kind regards,

Remco Poelstra
Labels (1)
0 Kudos
Reply
3 Replies

666 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by remcopoelstra on Sun Aug 31 07:12:34 MST 2014
Ok, that previous bug was caused by LPCExpresso not rebuilding my library dependencies.
I've to do a 'clean workspace' before it picks up changes to the libraries (yes, there are set as dependencies of the main project).
All is not solved, but I'll make a new thread for that, to keep the subject stick to the subject line....

Regards,

Remco Poelstra
0 Kudos
Reply

666 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by remcopoelstra on Sun Aug 31 04:48:34 MST 2014
Ah, yes, thanks!
Turned out I had some serious timing issues.
To solve those I switched to the ringbuffer UART driver.
Is the ringbuffer thread safe? I get data in the receive buffer that's never received over the line.
Since I heavily use the ringbuffer from the main thread while bytes come in I suspect that the main thread and interrupt are colliding.

Regards,

Remco Poelstra
0 Kudos
Reply

666 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by TheFallGuy on Fri Aug 29 09:07:56 MST 2014
That's not in an interrupt (if it was, you would still see the stack frames). The PC indicates you are in the ROM.

That would suggest you have stack corruption (something is overwriting your stack and when a call returns, it jumps off into the weeds).

0 Kudos
Reply