0
\$\begingroup\$

I'm trying to collect info on how to program ATSAMD10 chip (Atmel Cortex-M0 ARM).

E.g. with LPC111x from NXP I've used gnueabi gcc toolchain to create hex-files and then uploaded them via UART using LPC21PRG or MXLI tool. It only required to drive low PIN0_0 during reset to enter bootloader programming mode.

As far as I can understand, for Atmel chips I need to use SAM-BA utility. However I could not at once find which pins help to enter bootloader mode, what minimal hardware configuration is needed etc. However as about firmware, I think the same gnueabi gcc and hex files should be ok, right?

\$\endgroup\$
  • \$\begingroup\$ I would expect the GNU tool to do exactly what you need. However, Atmel are pushing people to use their Atmel Studio software. Are you unwilling or unable to use that? Are you using a development board? if so which board are you using? \$\endgroup\$ – gbulmer Dec 16 '15 at 10:50
  • \$\begingroup\$ I do not use any special development board. just UART and GND pins out of the device to connect to them. This was sufficient for my needs with NXP chips... \$\endgroup\$ – Rodion Gorkovenko Dec 16 '15 at 12:53
1
\$\begingroup\$

I would expect the GNU tool to do exactly what you need. It is a standard Cortex-M0, so the code generated will work. However, you will need startup code to initialise the peripherals, and library code to use the peripheral interfaces.

Atmel are pushing people to use their Atmel Studio software for upload.

AFAIK, there is no guarantee that software can be uploaded via UART on a raw (newly manufactured, unprogrammed) AT SAMD10. Looking at the AT SAMD10 datasheet there is no serial bootloader built into the chip.

So you need to load one, and flash it into the chip. This, of course, is a 'chicken and an egg' bootstrapping problem. I've done a quick web search, and haven't found a serial bootloader for the SAMD10, so their may be no serial bootloader, and you'll have to write it.

Instead of a serial (USART) botloader, you could use a hardware upload/debugger which connects over the ARM two wire SWD interface (the two pins SWDIO and SWCLK). This can program a raw AT SAMD10.

Look at the AT SAMD10 datasheet 6.2.2 "Serial Wire Debug Interface Pinout" for more details.

The SAM D10 Xplained Mini demo-board includes a hardware upload/debugger. They are under $10, so that is likely the cheapest way to get an upload system. The interface is USB.

You could buy more expensive products from Atmel, or look at OpenOCD (though I can't find SAMD10 support), or look at other hardware debuggers like Segger J-Link.

The issue is not that ARM's SWD interface is proprietary, it is the protocol from the host to the debugger which is the problem.

That will need some software to drive it. AFAICT BOSSA from Shumatech provides an Open Source alternative to the Atmel SAM-BA utility. Unlike the Atmel SAM-BA utility they say "Versions of BOSSA are available for Windows, Linux, and Mac".

\$\endgroup\$
  • \$\begingroup\$ "Looking at the AT SAMD10 datasheet there is no serial bootloader built into the chip" Yes, I also could not find this info, that is why I came here... But it seems I was slow to believe they simply do not have the preinstalled bootloader at all :( Thank you for explaining other options. Right now it seems the best is to stick with NXP chips (I start wondering because I could not always find them readily accessible). \$\endgroup\$ – Rodion Gorkovenko Dec 16 '15 at 13:11
  • \$\begingroup\$ As well as ARM, I use Arduino's, so a UART-based serial loader is fine. However, a SWD/JTAG hardware debugger is a wonderful tool. I would suggest that, if you have time and money, that you do experiment with it. I use STM32 Nucleo's which are good, come in a wide range of options, and are cheap. \$\endgroup\$ – gbulmer Dec 16 '15 at 21:21
  • \$\begingroup\$ While SWD is not proprietary, it is also not enough to load a program into FLASH - for that, you have to know how to write to flash on the given MCU, so that you know what operations to perform with the SWD. This information is also typically published, but it has to be implemented in software on the host and/or SWD adapter, so while generic SWD interfaces are in theory capable of supporting multiple targets, target-specific software support is required if you want to make any lasting changes. \$\endgroup\$ – Chris Stratton Jun 12 '16 at 19:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.