Introduce Atmel XMEGA CPU

[nandojve]

Description

I noted that current RIOT-OS doesn't have support for XMEGA CPUs. After some research I found a 2018 version from @Josar, which seams as a good start point.

I adjusted the code and made some rework on atmega_. With that, I could share the fundamental code for both CPUs. These means, ATmega and ATxmega will follow different paths for drivers and configurations but can have the same core, which I named avr8_.

I opened this Feature Request to centralize and collect all missing parts to introduce Xmega support on RIOT-OS.

Useful links

The #15712 is a proposal to split atmega_ into atmega_ and avr8_ to pave the path to introduce atxmega_ and/or attiny_.

The following branch introduce_avr8_xmega add XMEGA-A1 Xplained Pro as a prove of concept using ATxmega128A1U MCU. The work is based on @Josar 's XMEGA branch.

How to evaluate

The first thing is add xplainedpro_pdi programmer at /etc/avrdude.conf

programmer
  id    = "xplainedpro_pdi";
  desc  = "Atmel AVR XplainedPro in PDI mode";
  type  = "jtagice3_pdi";
  connection_type = usb;
  usbpid = 0x2111;
;

The port was tested using Tutorials/task-01 executing below command:

BOARD=atxmega-a1-xpro make all flash term

I hope this could be good for the project. I had boards with xmega and rf2xx 2.4 and sub-giga radios and would like introduce that boards soon.

CC: @benpicco

[maribu]

The below link is a proposal to split atmega_ into atmega_ and avr8_ to pave the path to introduce atxmega_.

This sounds very reasonable to me. IMO it would be the easiest to just PR the change to get feedback for it.

BOARD=wm200-xmegaa3 make all flash term

Can you provide a link for this board? Alternatively (and IMO preferably), would you consider adding the XMEGA-A3BU Xplained as first board for the ATxmega256A3BU MCU? The official evaluation boards are usually as long commercially available as the MCU is not flagged obsolete and are often easy to use for development and debugging due to an integrated programmer/debugger or (as in this case) at least standard debug connectors. As this board is (at least for Atmel/Microchip hardware) not relatively affordable, I could obtain one of these in order to help with testing and reviews.

[nandojve]

Thanks for the feedback @maribu !

The below link is a proposal to split atmega_ into atmega_ and avr8_ to pave the path to introduce atxmega_.

This sounds very reasonable to me. IMO it would be the easiest to just PR the change to get feedback for it.

Understood! I need read docs to make sure I'll follow procedures when open PR.

BOARD=wm200-xmegaa3 make all flash term

Can you provide a link for this board?

This board was developed by me and there is no public link. Attached a PDF for reference.
WM-200.pdf

Alternatively (and IMO preferably), would you consider adding the XMEGA-A3BU Xplained as first board for the ATxmega256A3BU MCU?

Sure, no big deal!

BTW, I added a missing commit couple minutes ago at introduce_avr8_xmega. It reworks a little bit the context switch and thread stack init. With that, I hope, all AVR-8 will work without looking any device itself.

[nandojve]

Hi @maribu,

I noted that exists XMEGA-A1U Xplained Pro board. With this, you have access to a CDC COM port and a debugger. I believe it will be easier to test XMEGA with A1 instead A3BU.

Do you think it will be better introduce XMEGA-A1U Xplained Pro board first?

[maribu]

That board would be indeed better. Note however that this is a different MCU - but without having read either datasheet I would guess the difference is mostly the available memory. If that is true, this would indeed be easier to work with :-)

[nandojve]

Yep, it is true! The differences in a practical term: only A1(U) variant have RAMPD, RAMPDX and RAMPDY registers to address more than 64k data.

I think it'll not be an issue since I already have both A1/A3 variants working with RIOT-OS.
I'll focus on the A1 to make life easy :-)

[nandojve]

Folks!

I just sent an update at introduce_avr8_xmega with XMEGA-A1 Xplained Pro working. The board arrived at this morning and I already validated. for sure XMEGA-A1 Xplained Pro will be the easiest board to develop and test.

@maribu, thank you for all help with #15712.

[nandojve]

More good news!

The xmega_ebi branch allow to test:

• SPI driver
• AT86RF2xx transceiver (XMEGA-A1 Xplained Pro + REB-233)
• External Bus Interface (EBI) to evaluate the 512k SRAM with XMEGA-A1 Xplained Pro.
  • The xmega have a limitation that allows only 64K SRAM to be used by RTOS. The remaining memory can be used using
    special methods. So, this allows to use up to 64K SRAM with RIOT-OS. The limitation happen because the CPU Stack
    registers can address up to 64K.
  • I'm not complete sure but I think external memory need to be overlapped with internal memory. Without that system not work.
    This means that first 8K external memory are lost!
• CPUID is used as EUI provider.
• Added peripheral power manager method.

I tested with Tutorials/task-06:

AVR Memory Usage
----------------
Device: Unknown

Program:   98582 bytes
(.text + .data + .bootloader)

Data:      21505 bytes
(.data + .bss + .noinit)

avrdude -c xplainedpro_pdi -p x128a1u -e -U flash:w:/home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e974c (probably x128a1u)
avrdude: erasing chip
avrdude: reading input file "/home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf"
avrdude: input file /home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf auto detected as ELF
avrdude: writing flash (98582 bytes):

Writing | ################################################## | 100% 3.07s

avrdude: 98582 bytes of flash written
avrdude: verifying flash memory against /home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf:
avrdude: load data flash data from input file /home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf:
avrdude: input file /home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf auto detected as ELF
avrdude: input file /home/gfbudke/riot-os/Tutorials/task-06/bin/atxmega-a1-xpro/Task06.elf contains 98582 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.94s

avrdude: verifying ...
avrdude: 98582 bytes of flash verified

avrdude done.  Thank you.

/home/gfbudke/riot-os/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"  
Twisted not available, please install it if you want to use pyterm's JSON capabilities
2021-01-23 19:52:34,467 # Connect to serial port /dev/ttyACM0
2021-01-23 19:52:35,470 # 

Welcome to pyterm!
Type '/exit' to exit.
2021-01-23 19:52:35,473 # main(): This is RIOT! (Version: 2021.04-devel-102-ga8508-xmega_ebi)
2021-01-23 19:52:35,473 # This is Task-06
> 
help
2021-01-23 19:52:39,651 #  help
2021-01-23 19:52:39,654 # Command              Description
2021-01-23 19:52:39,658 # ---------------------------------------
2021-01-23 19:52:39,661 # udp                  send udp packets
2021-01-23 19:52:39,664 # udps                 start udp server
2021-01-23 19:52:39,667 # reboot               Reboot the node
2021-01-23 19:52:39,672 # version              Prints current RIOT_VERSION
2021-01-23 19:52:39,676 # pm                   interact with layered PM subsystem
2021-01-23 19:52:39,682 # ps                   Prints information about running threads.
2021-01-23 19:52:39,685 # ping6                Ping via ICMPv6
2021-01-23 19:52:39,688 # ping                 Alias for ping6
2021-01-23 19:52:39,692 # random_init          initializes the PRNG
2021-01-23 19:52:39,697 # random_get           returns 32 bit of pseudo randomness
2021-01-23 19:52:39,702 # nib                  Configure neighbor information base
2021-01-23 19:52:39,706 # ifconfig             Configure network interfaces
2021-01-23 19:52:39,711 # 6ctx                 6LoWPAN context configuration tool
> ifconfig
2021-01-23 19:52:47,114 #  ifconfig
2021-01-23 19:52:47,120 # Iface  6  HWaddr: 0A:0A  Channel: 26  Page: 0  NID: 0x23  PHY: O-QPSK 
2021-01-23 19:52:47,122 #           
2021-01-23 19:52:47,126 #           Long HWaddr: 38:57:33:38:31:31:0A:0A 
2021-01-23 19:52:47,133 #            TX-Power: 0dBm  State: TX  max. Retrans.: 3  CSMA Retries: 4 
2021-01-23 19:52:47,141 #           AUTOACK  ACK_REQ  CSMA  L2-PDU:102  MTU:1280  HL:64  6LO  
2021-01-23 19:52:47,143 #           IPHC  
2021-01-23 19:52:47,146 #           Source address length: 8
2021-01-23 19:52:47,149 #           Link type: wireless
2021-01-23 19:52:47,154 #           inet6 addr: fe80::3a57:3338:3131:a0a  scope: link  VAL
2021-01-23 19:52:47,157 #           inet6 group: ff02::1
2021-01-23 19:52:47,158 #           

[nandojve]

Hello Folks,

I've been working in the USB driver for XMEGA. It still have some small issues but I already have a working version, see below:

tests/usbus_cdc_acm_stdio:

   text	   data	    bss	    dec	    hex	filename
  22212	   1776	   3460	  27448	   6b38	RIOT/tests/usbus_cdc_acm_stdio/bin/atxmega-a1-xpro/tests_usbus_cdc_acm_stdio.elf

CDC-ACM working:

make BOARD=atxmega-a1-xpro term
/home/gfbudke/riot-os/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"  
Twisted not available, please install it if you want to use pyterm's JSON capabilities
2021-02-17 18:53:53,223 # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
2021-02-17 18:53:59,755 # Serial port disconnected, waiting to get reconnected...
2021-02-17 18:54:00,758 # Serial port disconnected, waiting to get reconnected...
2021-02-17 18:54:01,758 # Serial port disconnected, waiting to get reconnected...
2021-02-17 18:54:02,760 # Serial port disconnected, waiting to get reconnected...
2021-02-17 18:54:03,761 # Try to reconnect to /dev/ttyACM0 again...
2021-02-17 18:54:03,764 # Reconnected to serial port /dev/ttyACM0
2021-02-17 18:54:03,766 # main(): This is RIOT! (Version: 2021.04-devel-223-ga40ec-xmega_ebi)
2021-02-17 18:54:03,767 # RIOT USB CDC ACM shell test
> text 32
2021-02-17 18:54:12,098 #  text 32
2021-02-17 18:54:12,102 # 01234567890123456789012345678901
> 2021-02-17 18:54:21,027 # Exiting Pyterm

The problems I've been facing are related with some instability. Eventually, there are problems to enumerate and hangs at CDC-ACM, for instance. I believe there is something basic that is missing.

Did you know something that allows me to test the firmware FSM from Linux host?
DEBUG isn't really helpful because of USB timings.

[  767.897891] usb 1-9: USB disconnect, device number 7
[  768.417465] usb 1-9: new full-speed USB device number 8 using xhci_hcd
gfbudke@Capricornio:~/riot-os/RIOT/tests/usbus_cdc_acm_stdio$ sudo dmesg -c
gfbudke@Capricornio:~/riot-os/RIOT/tests/usbus_cdc_acm_stdio$ sudo dmesg -c
gfbudke@Capricornio:~/riot-os/RIOT/tests/usbus_cdc_acm_stdio$ sudo dmesg -c
gfbudke@Capricornio:~/riot-os/RIOT/tests/usbus_cdc_acm_stdio$ sudo dmesg -c
[  773.657623] usb 1-9: unable to read config index 0 descriptor/all
[  773.657632] usb 1-9: can't read configurations, error -110
[  773.785594] usb 1-9: new full-speed USB device number 9 using xhci_hcd
[  773.939737] usb 1-9: New USB device found, idVendor=1209, idProduct=7d01, bcdDevice= 0.00
[  773.939741] usb 1-9: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[  773.943486] usb 1-9: can't set config #1, error -71

[maribu]

@bergzand might have an idea. I'm not really familiar with the USB stack :-(

[nandojve]

Is there any chance RIOT have a sample like this:
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/usb/testusb

I believe it uses only a bulk loopback EP. With that, it is possible run the testusb tool in linux/tools/usb.
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/loopback.c

[nandojve]

One thing that I realize is that below block can be shared between ATxmega and ATmega. There are defines between all models. This change require that ATmega drivers should implement pm_block/unblock when appropriated. The constants SLEEP_SMODE_xxx_gc should be switched to SLEEP_MODE_xxx. With this, PM can be fully enabled for ATmega's too.

RIOT/cpu/atxmega/periph/pm.c

Lines 50 to 80 in cf194d1

	void pm_set(unsigned mode)
	{
	unsigned irq_state = irq_disable();
	if (avr8_is_uart_tx_pending() && mode < 4) {
	irq_restore(irq_state);
	return;
	}
	switch (mode) {
	case 0:
	set_sleep_mode(SLEEP_SMODE_PDOWN_gc);
	break;
	case 1:
	set_sleep_mode(SLEEP_SMODE_PSAVE_gc);
	break;
	case 2:
	set_sleep_mode(SLEEP_SMODE_STDBY_gc);
	break;
	case 3:
	set_sleep_mode(SLEEP_SMODE_ESTDBY_gc);
	break;
	default:
	set_sleep_mode(SLEEP_SMODE_IDLE_gc);
	}
	sleep_enable();
	sei();
	sleep_cpu();
	sleep_disable();
	irq_restore(irq_state);
	}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[nandojve]

Xmega is working on the main tree and the main objective was done!
Thank you all reviewers.