Reply
Posts: 3
Registered: ‎06-21-2017

Printf break

[ Edited ]

Hey guys i am new to simplicity studio and was n trying to print out some sensor values .

So i have a print statement that i have redirected using retarget serial.c. 

while{
printf("here\n");
}

 

But when i connect to  a serial port and go i get the following output on my terminal

 

here

here

here

here

here

he"

 

 

after this it randomly stops and spurts out random characters . I paused the program using the debugger and noticed it stopped at  while (!(usart->STATUS & USART_STATUS_TXBL)) in uart_tx

Any suggestions on how may i proceed with this?

i need it to continuosly print out sensor readings

thank you

Posts: 3,092
Registered: ‎02-07-2002

Re: Printf break

Since the program will spend most of its time waiting in that loop, it is not surprising that you break there.

 

Do you maybe have a watchdog biting or some other reset cause? It could make the serial data train hicup and get out of sync. I suspect the data comes continously without inter-character delays.

Posts: 3
Registered: ‎06-21-2017

Re: Printf break ; Problems with uartdrv

So i took a logic analyser to see exactly what was being sent . The first chunk of data that was sent was labelled as a frame error but following the the rest of the data was being sent continuosly and was being detected by the logic analyser. But the terminal on my computer doesnt display anything. So i tried another approach using uartdrv  provided in the mighty gecko software documentation.
 
 
 
#include "uartdrv.h"
 
// Define receive/transmit operation queues
DEFINE_BUF_QUEUE(EMDRV_UARTDRV_MAX_CONCURRENT_RX_BUFS, rxBufferQueue);
DEFINE_BUF_QUEUE(EMDRV_UARTDRV_MAX_CONCURRENT_TX_BUFS, txBufferQueue);
 
// Configuration for USART0, location 11
#define MY_UART \
{ \
USART0, \
115200, \
_USART_ROUTELOC0_TXLOC_LOC11, \
_USART_ROUTELOC0_RXLOC_LOC11, \
usartStopbits1, \
usartNoParity, \
usartOVS16, \
false, \
uartdrvFlowControlHwUart, \
gpioPortA, \
4, \
gpioPortA, \
5, \
(UARTDRV_Buffer_FifoQueue_t *)&rxBufferQueue, \
(UARTDRV_Buffer_FifoQueue_t *)&txBufferQueue, \
_USART_ROUTELOC1_CTSLOC_LOC11, \
_USART_ROUTELOC1_RTSLOC_LOC11 \
}
 
UARTDRV_Handle_t handle = &handleData;
uint8_t buffer[64];
 
void callback(UARTDRV_Handle_t handle,
Ecode_t transferStatus,
uint8_t *data,
UARTDRV_Count_t transferCount)
{
(void)handle;
(void)transferStatus;
(void)data;
(void)transferCount;
}
 
void main(void)
{
// Initialize driver handle
UARTDRV_InitUart_t initData = MY_UART;
UARTDRV_InitUart(handle, &initData);
 
// Transmit data using a non-blocking transmit function
UARTDRV_Transmit(handle, buffer, 64, callback);
}
 
I put data into the buffer and compiled the code in a main successfully. But when  i checked the port a0 and a1 (i.e which is assigned for usart0) nothing shows up . Is there anything else i should be doing configuration wise?
Highlighted
Posts: 3,092
Registered: ‎02-07-2002

Re: Printf break ; Problems with uartdrv

After a frame error a uart needs some quiet time on the line to resynchronize. A continuous transmission can keep it out of sync.

Posts: 469
Registered: ‎01-18-2004

Re: Printf break ; Problems with uartdrv


vanmierlo wrote:

After a frame error a uart needs some quiet time on the line to resynchronize. A continuous transmission can keep it out of sync.


I forget what exactly that "quiet time" after a byte is sent, but I think it's on the order of a bit time after the stop bit is transmitted. If you consider that at 115200 bps the bit time is 8.68 us, that's forever when the processor clock speed is a measly 25 MHz (40 ns). The DMA engine controlling the transmission can see that the transmit shift is complete, perhaps meaning "stop bit just started transmitting," because the stop bit idles the TX line. And then in a very few clock ticks it can turn around and start sending the next byte, indicated by bringing the TX line low for the start bit. The receiver may not be ready for that event.

Posts: 3,092
Registered: ‎02-07-2002

Re: Printf break ; Problems with uartdrv

I'm sure the UART will wait the full stop bit before transmitting the next start bit. But when you go out of sync that is not enough. In that case you need a full byte of silence to recover, because the next start bit may be interpreted as part of the previous byte and the receiver may think any of the following '0' bits is the start bit.Using two stop bits on transmit helps to stay in sync.