SAM20 STDIO SERIAL/USART printf issue

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

I'm currently using SAMD20G18A on a custom board to monitor some voltages via the ADC. I want to transmit the temperatures collected using USART to the PC, to be displayed on putty or teraterm. So I decided to use a simple hello world program using ASF 3.36 which has a Standard serial I/O driver. Since PBCKCODE is not letting me add the code, please find attached main.c

 

Do I need to add something else to get it working? When I try to single step the printf, it just skips and moves to the delay.

 

Regards,

Jenson

Attachment(s): 

This topic has a solution.

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Fri. Jan 5, 2018 - 04:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The getting started examples don't init the usart (stdio_serial_init does that).

static void configure_console(void)
{
	struct usart_config usart_conf;

	usart_get_config_defaults(&usart_conf);
	usart_conf.mux_setting = CONF_STDIO_MUX_SETTING;
	usart_conf.pinmux_pad0 = CONF_STDIO_PINMUX_PAD0;
	usart_conf.pinmux_pad1 = CONF_STDIO_PINMUX_PAD1;
	usart_conf.pinmux_pad2 = CONF_STDIO_PINMUX_PAD2;
	usart_conf.pinmux_pad3 = CONF_STDIO_PINMUX_PAD3;
	usart_conf.baudrate    = CONF_STDIO_BAUDRATE;

	stdio_serial_init(&cdc_uart_module, CONF_STDIO_USART_MODULE, &usart_conf);
	usart_enable(&cdc_uart_module);
}

/Lars

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

Lars,

 

I started with that code as reference, only printf seems to be not working. do I need to link another library apart from the Standard Serial I/O (driver) from ASF? Do I need write the read and write callbacks?

 

Regards,

Jenson

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Mon. Dec 4, 2017 - 05:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, I'm not getting any output apart from signal going high. Checking the output signal (TX) on an Oscilloscope. Pins I've chosen are 21(TX) and 22(RX), PA12D and PA13D respectively on Sercom 4. According to I/O multiplexing 

 

Can pins 21 and 22 be configured to transmit/receive as USART instead of them being used as I2C? Any internal pullups to be taken care of? 

 

ps: Please ignore this, USART transmit works, Putty settings were incorrect, I had to disable flow control, hardware connections to the carrier board DB15 connector were wrongly numbered. Spent a day trying to debug this *smashes head against the desk*.
 

Only issue remaining is getting 'printf' and 'puts' to work with current setup!!! Do I need to use the linker to link stdio.h with stdio_serial.h?

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Wed. Dec 6, 2017 - 07:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

*** ignore this, as I just scrolled far enough to see OP say ignore this... leaving it as an alternate thing for the next person to explore if they run afoul of SERCOM too.

I do not have time to pull up the datasheet, but we just struggled with something similar on SAMD51J20...

Start configurator let us choose pins other than PAD0 for TXD.  In SAMD5x/SAME5x only pad0 in a given IOSET can be TX.  Took a little white wire to fix.

To see if your issue is pins vs. ASF, try setting registers in debugger.  Write a byte directly to TXDATA and scope the pins.

The manual is clear in hindsight.  

jeff

Last Edited: Thu. Dec 7, 2017 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

should be able to use something like this.  Tracing into it should go through all the low level steps needed to make the redirect.

My coworker is doing that part and we have not spoken since we figured out the TXD pad issue.

stdio_redirect_init();

jeff

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

Cheers for trying to help me out. TX and printf work fine. Only issue is that I can't seem to receive. Probably will have to scope the rx pin and see if it receives signal from the carrier board. Quite difficult to debug with the boards. Will need to double check if it's an issue with my code or they have once again messed up the DB15 connector line from the carrier board to the main board where the SAMD20 resides. 

 

Also, I'll try to write directly into the register using the debugger and see if my code handles any change in RXDATA !!! Need to make full use of your debugger capabilities. I keep forgetting we can do that. Thanks once again for that piece of information and I'm not going to forget this debug method. 

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Fri. Dec 8, 2017 - 06:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I am very new to Atmel but my mcu days extend back to i4004 and 8080/Z80...

I believe SERCOM has internal loopback?  If not, can you make a loopback connector so putting a byte in TX data returns it to RX data?

Also, is the peripheral running in debug or paused?

jeff

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

jcandle wrote:

I am very new to Atmel but my mcu days extend back to i4004 and 8080/Z80...

I believe SERCOM has internal loopback?  If not, can you make a loopback connector so putting a byte in TX data returns it to RX data?

Also, is the peripheral running in debug or paused?

Moving to ARM must have been a PITA. But having a software framework helps I guess. I wanted to start from scratch. But I don't have the time or expertise to dive into the deep end. Using a TI Cortex M4F at home to get used. I might get an Atmel SAMD21 board for hobby work. Slowly falling in love with Atmel even after the Microchip takeover. But most embedded folks seem to swear by STM arm boards this days. 

 

I was running the peripheral in debug with breakpoints at times. I'll try without it and see how it goes. I couldn't find any information about SERCOM having any internal loopback. Looks like you can't write into the RX_DATA register directly either. I am going to ask the Hardware guys to short the tx and rx pin on the microcontroller. I still think there might be an issue with the carrier board or the RS 422 connector circuitry. Either some resistor not loaded or some pin not enabled. But I need to have some proof  to show that the rx works fine on the microcontroller (software part).

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Wed. Dec 13, 2017 - 07:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'm looking at the D21 data sheet but I'd be surprised if the D20 would be different in this respect: Loopback of what the USART sends is available. Connect both Tx and Rx to the same pin.
.
Search the data sheet for "loop-back" (with a hyphen).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
I'm looking at the D21 data sheet but I'd be surprised if the D20 would be different in this respect: Loopback of what the USART sends is available. Connect both Tx and Rx to the same pin. . Search the data sheet for "loop-back" (with a hyphen).

 

Aha, I was searching through the SAMD20 ASF reference manual for that bit of information. Cheers for the pointing out that the information is the SAMD20 datasheet. I'm using ASF 3.36, so I'm guessing I'll have to directly write to the registers to configure the TX-RX as loop-back. Or probably just set the MUX settings to use a single pin as TX and RX.

 

Regards,
Jenson

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Wed. Dec 13, 2017 - 07:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

As i read the D21 sheet its the I/O multiplexing.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
As i read the D21 sheet its the I/O multiplexing.

Yes, just need to change the MUX settings to use the same pin. Internal loopback works. Most likely issue with carrier board RX hardware part.

Thanks a lot, Johan.

 

Regards,
Jenson  

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Wed. Dec 13, 2017 - 09:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
As i read the D21 sheet its the I/O multiplexing.

Can scanf() cause blocking if used with the Standard serial I/O (driver) ? Seems to be waiting in usart_read_wait. But with getchar or scanf of a single character seems to be working if use putchar. But I can't seem to send any data from TeraTerm. 

 

Newbie to the world of Atmel SAM D microcontrollers.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JensonPais wrote:

JohanEkdahl wrote:
As i read the D21 sheet its the I/O multiplexing.

Can scanf() cause blocking if used with the Standard serial I/O (driver) ? Seems to be waiting in usart_read_wait. But with getchar or scanf of a single character seems to be working if use putchar. But I can't seem to send any data from TeraTerm. 

 

 

RX Issue was with hardware. Converting RS-422 Differential signal to single ended for USART RX was cancelling out input. Works fine after a pulldown resistor fix. 

Thank you once everyone who has helped me in this thread, happy new year to you all.  

 

Summary post: Earlier TX issue Summary :USART transmit works, Putty settings were incorrect, I had to disable flow control, hardware connections to the carrier board DB15 connector were wrongly numbered. Spent a day trying to debug this *smashes head against the desk*.

Newbie to the world of Atmel SAM D microcontrollers.

Last Edited: Mon. Jan 8, 2018 - 06:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the feedback - now please mark the solution: https://www.avrfreaks.net/comment...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Thanks for the feedback - now please mark the solution: https://www.avrfreaks.net/comment...


 

Hi Neil,

 

I had already marked the solution for the original transmit issue. The last feedback was for the following receive issue!!!

 

Regards,

Jenson 

Newbie to the world of Atmel SAM D microcontrollers.

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

Ah - that's the trouble with tagging a new question onto an already-"solved" thread!

 

EDIT

 

You can only have 1 post mark as "The Solution", but you can change which post you mark.

 

So perhaps (as suggested in the link) you could create a summary post - and mark that as the solution to both your questions ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jan 4, 2018 - 10:57 AM