[Solved] Atmel Studio 6.0 SP2, Arduino Due/X ASF DACC example

Hello,

I am using Atmel studio 6 to program an Arduino Due R3 board, using the provide ASF examples for the Arduino. I can program the Arduino just fine, however there are issues with several of the examples that use the UART.

The specific example is DACC_SINWAVE_EXAMPLE which communicates a menu over the UART to a console. The menu is used to control the sin wave output (amplitude and frequency) to the DAC on the arduino board. The menu is sent over the UART to the terminal correctly, however when I try to select a menu item, my characters are not being transferred or communicated to the SAM3X correctly.

I've attached the main program, and an outline of he main while loop below:

//Main while loop outline
while (1) 
{
		usart_serial_getchar((Usart *)CONSOLE_UART, &uc_key);

		switch (uc_key) 
                {
		case '0':
		        //do stuff
			break;

		case '1':
		        //do stuff
			break;

		case 'i':
		case 'I':
		        //do stuff
			break;

		case 'w':
		case 'W':
		        //do stuff
			break;

		case 'm':
		case 'M':
			display_menu();
			break;

                case default:
                       puts(uc_key);
                       break;
		}
	
}

I have no idea what the problem is however it seems to be a problem with the following:

usart_serial_getchar((Usart *)CONSOLE_UART, &uc_key);

The ARM chip is not getting the correct characters, which I believe should be in the variable uc_key

Regardless of what I type into the console, the program always jumps to the default case. I added a puts(uc_key); to see exactly what is being sent over the UART, and it always returns the same weird characters regardless of the key I press:

 °)[07] ©	[08]

If anyone has any experience with this or more experience with the C/C++ than me, and can give me any insight it would be much appreciated.

Or if you have Atmel Studio 6, and can test this out on your due to confirm, that would also be helpful!

Best Regards,
Michael

sinewave_example.c (12.3 KB)

what device are you using between avrisp and the due ?
i wanted to know this

Hi Knuckles,

What do you mean? I am using just the Arduino Due connected to the programming port via USB, and using a terminal to Tx/Rx to the due.

I program the Due using BOSSA. The device that sits in between the SAM3x and the USB port is an ATMEGA16u2 which acts as as virtual serials port via USB.

Hello all,

I have confirmed this to be a problem from Atmel themselves. Please see below:

Hello,

I just had more inputs from the SW team.
The programming port is currently not supported in Studio: this feature was not available on the Developer Board we had from Arduino when developing ASF for the Due. The only way to program the Due using Studio today is to use the JTAG port and the serial communication must be done using the USB to Serial adapter or any FTDI adapter.

I did two tests to confirm this:

  • Run ASF examples with UART using the USB to Serial adapter: OK
  • Run the exact same ASF examples with UART using the programming port: KO. I reproduced your problem: menu is correctly displayed, but the characters sent are not valid.

So to me the problem is related to the ATMega firmware, which is maintained by Arduino. I contacted Arduino about this, but you can also try to contact them in parallel using the forum.

I also suspected the problem to lie in the ATMEGA16u2 firmware. I will investigate further. If anyone has tried this or has any input please reply. Also if you have any experience programming the 16u2 firmware please let me know.

I was told: http://arduino.cc/forum/index.php/topic,142608.0.html there is no DFU in the firmware for programming the 16u2 via USB and must use ISP. If anyone has experience with this please let me know.

Best Regards,
Michael

The solution provided by Arduino support.

Hi,

to allow full USB speed on the 16U2 chip we provided the 5V power supply to it. Then we added a level shifter on the RX0 to adapt the voltage levels between the 16u2 ic and the sam3x UART.

In order to have it working with the atmel tools and utilities you have to activate the pull-up resistor on the Serial port pins.

Kind,
Federico Vanzati support@arduino.cc

This means to use the Atmel examples one must enable the pull-up resistors on Tx0 and Rx0. To do this in the file: arduino_due_x.h of an ASF example

/* ------------------------------------------------------------------------ */
/* UART                                                                     */
/* ------------------------------------------------------------------------ */
/*! UART pins (UTXD0 and URXD0) definitions, PA8,9. (labeled RX0->0 and TX0->1)*/
#define PINS_UART        (PIO_PA8A_URXD | PIO_PA9A_UTXD)
#define PINS_UART_FLAGS  (PIO_PERIPH_A | PIO_PULLUP)

#define PINS_UART_MASK (PIO_PA8A_URXD | PIO_PA9A_UTXD)
#define PINS_UART_PIO  PIOA
#define PINS_UART_ID   ID_PIOA
#define PINS_UART_TYPE PIO_PERIPH_A
#define PINS_UART_ATTR PIO_PULLUP

Hi,
I have the same problem with receiving characters via programming port. To solve the problem, did you just put the code (mentioned below) for this to work or is it also required to use the pull-up resistors along with the macros (also mentioned below)? Besides, does this solution still requires the use of the 5V power connector?

Thanks in advance :slight_smile:

/* ------------------------------------------------------------------------ */
/* UART                                                                     */
/* ------------------------------------------------------------------------ */
/*! UART pins (UTXD0 and URXD0) definitions, PA8,9. (labeled RX0->0 and TX0->1)*/
#define PINS_UART        (PIO_PA8A_URXD | PIO_PA9A_UTXD)
#define PINS_UART_FLAGS  (PIO_PERIPH_A | PIO_PULLUP)

#define PINS_UART_MASK (PIO_PA8A_URXD | PIO_PA9A_UTXD)
#define PINS_UART_PIO  PIOA
#define PINS_UART_ID   ID_PIOA
#define PINS_UART_TYPE PIO_PERIPH_A
#define PINS_UART_ATTR PIO_PULLUP

Hi,
I ran into the same trouble with ALL OTHER examples using the UART interfaze. Due sent data but wasn't able to receive.

In order to have it working with the atmel tools and utilities you have to activate the pull-up resistor on the Serial port pins.
Kind,
Federico Vanzati support@arduino.cc

This didn't work for me - in fact it was vice-versa.

In pio.c I found:

 pio_configure_pin_group() {}
	/* Configure pins */
	switch (ul_flags & PIO_TYPE_Msk) {
	case PIO_TYPE_PIO_PERIPH_A:
		pio_set_peripheral(p_pio, PIO_PERIPH_A, ul_mask);
		pio_pull_up(p_pio, ul_mask, (ul_flags & PIO_PULLUP));
		break;

which made the trouble.

My assumption:
The Pull-ups of the UART line are active. So the Tx-line runs to 3.3V instead to gnd after each data transmitted causing the receiver to frown since he cannot find the start (transition low-high) of the start bit. I disabled the code line:

pio_pull_up(p_pio, ul_mask, (ul_flags & PIO_PULLUP));

and then it worked.

Besides, does this solution still requires the use of the 5V power connector?

The whole uC is independent of the 5V rail. For the DAC only V_dd_ana (3.3V) is neccessary for the SAM3X which is already soldered btw.

I don't recommend to use the 5V line at all since it can do a lot of serious damage by inadvertently connect a I/O pin to it. Bummer the I/O are not 5V tolerant as they are by so many other different processor families.

Transistorfips:
Hi,
I ran into the same trouble with ALL OTHER examples using the UART interfaze. Due sent data but wasn't able to receive.

In order to have it working with the atmel tools and utilities you have to activate the pull-up resistor on the Serial port pins.
Kind,
Federico Vanzati support@arduino.cc

This didn't work for me - in fact it was vice-versa.

In pio.c I found:

 pio_configure_pin_group() {}
/* Configure pins */
switch (ul_flags & PIO_TYPE_Msk) {
case PIO_TYPE_PIO_PERIPH_A:
	pio_set_peripheral(p_pio, PIO_PERIPH_A, ul_mask);
	pio_pull_up(p_pio, ul_mask, (ul_flags & PIO_PULLUP));
	break;



which made the trouble.



My assumption: 
The Pull-ups of the UART line are active. So the Tx-line runs to 3.3V instead to gnd after each data transmitted causing the receiver to frown since he cannot find the start (transition low-high) of the start bit. I disabled the code line:


pio_pull_up(p_pio, ul_mask, (ul_flags & PIO_PULLUP));



and then it worked.




> Besides, does this solution still requires the use of the 5V power connector?


The whole uC is independent of the 5V rail. For the DAC only V_dd_ana (3.3V) is neccessary for the SAM3X which is already soldered btw.

I don't recommend to use the 5V line at all since it can do a lot of serious damage by inadvertently connect a I/O pin to it. Bummer the I/O are not 5V tolerant as they are by so many other different processor families.

Thank you very much for the input. I'll try that this week.
Cheers :slight_smile:

As of Atmel Studio 6.2.933 Beta, this problem has NOT been "[SOLVED]". Or maybe I'm running old firmware in the ATMEGA16u2 chippie?

However, that assessment that the Arduino DUE's Uart gpio pin needs to be configured with a pullup is correct. None of the Atmel Studio 6.2.933 Bet Arduino DUE/X examples allow input from the UART attached to the programming port (actually input is recognized as having occurred, but always returns a value of 0).

I made the following change to init.c as found in the Atmel studio sources:

#ifdef CONF_BOARD_UART_CONSOLE
/* Configure UART pins */
gpio_configure_group(PINS_UART_PIO, PINS_UART, PINS_UART_FLAGS);
#endif

to

#ifdef CONF_BOARD_UART_CONSOLE
/* Configure UART pins */
gpio_configure_group(PINS_UART_PIO, PINS_UART, PINS_UART_FLAGS | PIO_PULLUP);
#endif

which at least allows the Arduino DUE to read input from the PC over the programming port (I use a Jlink to flash).

and finally... Atmel/Arduino one year and no update? You should be embarrassed.

I am glad to find the solution here. It has been troubling me for over a week!!!