Atmel SAM R21 Xplained Pro¶
Support for the Atmel SAM R21 Xplained Pro board.
Overview¶
The SAMR21 Xplained Pro is a compact evaluation board by Atmel featuring a ATSAMR21G18A SoC. The SoC includes a SAMD21 ARM Cortex-M0+ micro-controller bundled with Atmel’s AT86RF233, a 2.4GHz IEEE802.15.4 compatible radio. For programming the MCU comes with 32Kb of RAM and 256Kb of flash memory.
The samr21-xpro is available from various hardware vendors for ~40EUR (as of sep. 2014).
Hardware¶
MCU¶
| MCU | ATSAMR21G18A |
|---|---|
| Family | ARM Cortex-M0+ |
| Vendor | Atmel |
| RAM | 32Kb |
| Flash | 256Kb |
| Frequency | up to 48MHz |
| FPU | no |
| Timers | 6 (1x 16-bit, 2x 24-bit, 3x 32-bit) |
| ADCs | 1x 12-bit (8 channels) |
| UARTs | max 5 (shared with SPI and I2C) |
| SPIs | max 5 (see UART) |
| I2Cs | max 5 (see UART) |
| Vcc | 1.8V - 3.6V |
| Datasheet | Datasheet |
| Board Manual | Board Manual |
Radio¶
The SAMR21 SoC includes an on-chip AT86RF233 radio. It is internally connected via SPI and some GPIO pins and behaves in exact the same way as externally connected SPI devices.
| Sensor | AT86RF233 |
|---|---|
| Type | 2.4GHz IEEE802.15.4 radio |
| Vendor | Atmel |
| Datasheet | Datasheet |
| Connected to | SPI_0 |
| Pin Config: | |
| Device | SERCOM4 |
| MOSI | PB30 (OUT, SPI mosi) |
| MISO | PC19 (IN, SPI miso) |
| SCLK | PC18 (OUT, SPI sclk) |
| CS | PB31 (OUT, GPIO output) |
| IRQ | PB00 (IN, GPIO external interrupt) |
| RSTN | PB15 (OUT, GPIO output) |
| SLP_TR | PA20 (OUT, GPIO output) |
MCU¶
| MCU | ATSAMR21G18A |
|---|---|
| Family | ARM Cortex-M0+ |
| Vendor | Atmel |
| RAM | 32Kb |
| Flash | 256Kb |
| Frequency | up to 48MHz |
| FPU | no |
| Timers | 6 (1x 16-bit, 2x 24-bit, 3x 32-bit) |
| ADCs | 1x 12-bit (8 channels) |
| UARTs | max 5 (shared with SPI and I2C) |
| SPIs | max 5 (see UART) |
| I2Cs | max 5 (see UART) |
| Vcc | 1.8V - 3.6V |
| Datasheet | Datasheet |
| Board Manual | Board Manual |
Radio¶
The SAMR21 SoC includes an on-chip AT86RF233 radio. It is internally connected via SPI and some GPIO pins and behaves in exact the same way as externally connected SPI devices.
| Sensor | AT86RF233 |
|---|---|
| Type | 2.4GHz IEEE802.15.4 radio |
| Vendor | Atmel |
| Datasheet | Datasheet |
| Connected to | SPI_0 |
| Pin Config: | |
| Device | SERCOM4 |
| MOSI | PB30 (OUT, SPI mosi) |
| MISO | PC19 (IN, SPI miso) |
| SCLK | PC18 (OUT, SPI sclk) |
| CS | PB31 (OUT, GPIO output) |
| IRQ | PB00 (IN, GPIO external interrupt) |
| RSTN | PB15 (OUT, GPIO output) |
| SLP_TR | PA20 (OUT, GPIO output) |
Implementation Status¶
Please refer to this tracker to see which projects are work in progress and who is the contact person for this.
| Device | ID | Supported | Comments |
|---|---|---|---|
| MCU | samd21 | partly | Energy saving modes not fully utilized |
| Low-level driver | GPIO | yes | |
| PWM | yes | ||
| UART | yes | two UARTs by now | |
| I2C | yes | ||
| SPI | yes | ||
| ADC | yes | PA04 & PA05 disabled by default due to EDBG’s use of them for UART, can be enabled from periph_conf.h |
|
| USB | no | ||
| RTT | yes | ||
| RTC | yes | ||
| RNG | no | no HW module | |
| Timer | yes | ||
| Radio Chip | AT86RF233 | yes | using at86rf231 driver (this will be renamed to at86rf2xx) |
Flashing the device¶
Connect the device to your Micro-USB cable using the port labeled as EDBG.
The standard method for flashing RIOT to the samr21-xpro is using OpenOCD. For this to work properly, you have to make sure to use a very recent version of OpenOCD. The v0.8.0 release will not work. If this is still the current release you’ll have to build OpenOCD from source.
Refer to https://github.com/RIOT-OS/RIOT/wiki/OpenOCD for building OpenOCD and make sure “cmsis-dap” and “hidapi-libusb” are enabled.
On Linux you will have to add a udev rule for hidraw, like
1 2 3 4 | bash
echo 'KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"' \
| sudo tee -a /etc/udev/rules.d/99-usb.rules
sudo service udev restart
|
Arch Linux¶
With yaourt:
1 2 3 | yaourt -S hidapi-git
yaourt -S openocd-git
# edit PKGBUILD, make sure "hidapi-libusb" is in "_features"
|
The udev rules for Arch differ a little from the example given above:
1 2 3 4 | bash
echo 'KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="uucp"' \
| sudo tee -a /etc/udev/rules.d/99-usb.rules
sudo udevadm control --reload
|
Ubuntu¶
Arch Linux¶
With yaourt:
1 2 3 | yaourt -S hidapi-git
yaourt -S openocd-git
# edit PKGBUILD, make sure "hidapi-libusb" is in "_features"
|
The udev rules for Arch differ a little from the example given above:
1 2 3 4 | bash
echo 'KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="uucp"' \
| sudo tee -a /etc/udev/rules.d/99-usb.rules
sudo udevadm control --reload
|
Ubuntu¶
Connecting multiple boards¶
If you have multiple boards connected to the same computer and want to flash, this is what you can do:
First, run make list-ttys. This will show you a list of currently connected boards, their serial numbers and the names of their TTYs: ttyACM0 Atmel Corp. EDBG CMSIS-DAP serial: ‘ATML2127031800002145’, tty(s): ttyACM1
knowing your serial number, you can flash, open a terminal or debug a specific board like this:
Supported Toolchains¶
For using the samr21-xpro board we strongly recommend the usage of the GNU Tools for ARM Embedded Processors toolchain.
Known Issues / Problems¶
I2C¶
When connecting an I2C device and a logic analyzer to an I2C port at the same time, the internal pull-up resistors are not sufficient for stable bus operation. You probably have to connect external pull-ups to both bus lines. 10K is a good value to start with.
Stack sizes¶
The default stack sizes have not been tuned properly yet. If in doubt why your application crashes try increasing the default stack sizes and use ps to find out how much stack is being used. Tracked in https://github.com/RIOT-OS/RIOT/issues/2228
User Button¶
When using the SW0 user button as interrupt source it appears that this is triggered when just tipping on the button and not really pressing it.
Not flashable by OpenOCD anymore¶
It can happen that OpenOCD is not able to program the board, because of wrong clock configuration or low power modes. In this case you can use this little tool to erase the flash. Just follow the instructions to build it and run ./edbg -e to erase the flash. Then press the reset button and you’re able to program via OpenOCD again.
Flashing might not work in Virtual Box with Mac OS X as host¶
It might happen that flashing through OpenOCD works once inside Virtual Box. But when you try to flash again, you could get a CMSIS-DAP related error. It seems to only happen with USB 3.0 ports. You can take a look at Vagrant and use a virtual Linux to run the virtual RIOT, and flash from OS X.
I2C¶
When connecting an I2C device and a logic analyzer to an I2C port at the same time, the internal pull-up resistors are not sufficient for stable bus operation. You probably have to connect external pull-ups to both bus lines. 10K is a good value to start with.
Stack sizes¶
The default stack sizes have not been tuned properly yet. If in doubt why your application crashes try increasing the default stack sizes and use ps to find out how much stack is being used. Tracked in https://github.com/RIOT-OS/RIOT/issues/2228
User Button¶
When using the SW0 user button as interrupt source it appears that this is triggered when just tipping on the button and not really pressing it.
Not flashable by OpenOCD anymore¶
It can happen that OpenOCD is not able to program the board, because of wrong clock configuration or low power modes. In this case you can use this little tool to erase the flash. Just follow the instructions to build it and run ./edbg -e to erase the flash. Then press the reset button and you’re able to program via OpenOCD again.
Flashing might not work in Virtual Box with Mac OS X as host¶
It might happen that flashing through OpenOCD works once inside Virtual Box. But when you try to flash again, you could get a CMSIS-DAP related error. It seems to only happen with USB 3.0 ports. You can take a look at Vagrant and use a virtual Linux to run the virtual RIOT, and flash from OS X.