Problem using Standard Serial I/O and SERCOM USART

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am currently working on an ASF based project that utilizes both the Standard Serial I/O and SERCOM USART drivers for SamL21 Xplained pro (ATSAML21J18B).  For the actual application I am using usart_read_buffer_job() function to fill up a 5 byte buffer.  I added a debug mode that prints to accepts commands from a console window using standard input functions printf() and getchar().  It works, but there is a bug somewhere that I can't seem to track down.  There are times when the code should be blocked at getchar() until I enter a byte through the console.  What is happening instead is that I have to enter 5 bytes which end up in the buffer that I use with usart_read_buffer_job().  I am configuring the drivers as follows:

 

void configure_usart(void)
{
	struct usart_config config_usart;
	usart_get_config_defaults(&config_usart);
	config_usart.baudrate    = 9600;
	config_usart.mux_setting = EXT2_UART_SERCOM_MUX_SETTING;
	config_usart.pinmux_pad0 = EXT2_UART_SERCOM_PINMUX_PAD0;
	config_usart.pinmux_pad1 = EXT2_UART_SERCOM_PINMUX_PAD1;
	config_usart.pinmux_pad2 = EXT2_UART_SERCOM_PINMUX_PAD2;
	config_usart.pinmux_pad3 = EXT2_UART_SERCOM_PINMUX_PAD3;
	while (usart_init(&usart_instance,EXT2_UART_MODULE
	, &config_usart) != STATUS_OK) {}
	//reroute std out to uart	
	stdio_serial_init(&usart_instance,EXT2_UART_MODULE, &config_usart);
	usart_enable(&usart_instance);
}
void usart_read_callback(struct usart_module *const usart_module)
{
	rx_buffer_full = true;
	
}
void configure_usart_callbacks(void)
{
	usart_register_callback(&usart_instance,
	usart_write_callback, USART_CALLBACK_BUFFER_TRANSMITTED);
	usart_register_callback(&usart_instance,
	usart_read_callback, USART_CALLBACK_BUFFER_RECEIVED);
	usart_enable_callback(&usart_instance, USART_CALLBACK_BUFFER_TRANSMITTED);
	usart_enable_callback(&usart_instance, USART_CALLBACK_BUFFER_RECEIVED);
}

I am using the following function to populate the 5 byte buffer:

void get_ui(void)
{
	while (rx_buffer_full == false) {
		usart_read_buffer_job(&usart_instance,
		(uint8_t *)rx_buffer, MAX_RX_BUFFER_LENGTH);
	}
	rx_buffer_full = false;
}

It's as if the get_ui() function is being called instead of getchar(), but I've tried placing breakpoints everywhere and can't determine what code is executing to put the console data into the buffer variable.  Is there something I should be doing differently to get the desired functionality?  Is there a way to step through the disassembly view?  Any help or suggestions would be greatly appreciated. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know SAM or ASF so this is a shot in the dark but surely once you have called a function that glues stdin/stdout to some specific uart you no longer would want to be calling any kind of direct uart_do_soemthing() function would you? I would have thought the idea of making the connection to stdin/stout is that from that moment on you use putchar()/puts()/printf()/etc outbound and getchar()/gets()/scanf()/etc inbound?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I may try that, at this point it's more about the aggravation of not knowing what my code is doing.  I can't seem to find a place to put a breakpoint when the problem arises, and I've looked through the call stack to see what functions are being called.  I'm completely stumped.  To be honest though I'm really not sure if using the two drivers and associated functions at once is a bad thing or not.  What I don't get is that on the surface I can't see anyway for my 5 character array to be accessed other than through a single function.  I plan on spending some more time looking at the disassembly this afternoon to see if I can trace back where the call is being made.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe I found a solution to the problem,  the function usart_read_buffer_job() sets a pointer to my rx_buffer array in the usart_module data structure.  By setting this to a null pointer before using stdio functions it seems to be working as expected.  I'm still confused on how the code execution seems to jump, I plan on investigating further if anyone has any suggestions.