Compiling for SAMD on the Raspberry Pi

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

Hi,

 

  I have a stupid question - a while back I bought some bare SAMD10 chips as part of a project I am slowly getting back around to. At the time I didn't have the facility to upload code to them.

 

I think I've solved this using an article I found. I realised that I don't actually have the facility to compile code for it!

 

I generally use a Mac for development but have set up a raspberry pi zero as a build platform which I use for developing for AVR using a little custom 'hat' that breaks out the SPI programming pins. I've recently designed a new hat to break out the SWD pins with the intention of using OpenOCD to program it but I don't know what compiler I need to install.

 

Is there an equivalent to avr-gcc for SAM-based arm? I haven't been able to find anything but search results get a bit muddied because the rasPi is arm based.

 

Thanks

-Mike

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

You want arm-eabi-none-gcc. This should narrow your search. Yes, it is available. Worst case you can compile it on the pi, but you really just want to download a package.

Last Edited: Fri. Nov 16, 2018 - 10:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

You want arm-eabi-none-gcc. This should narrow your search. Yes, it is available. Worst case you can compile it on the pi, but you really just want to download a package.

Great, thank you. I had seen that in results but wasn't sure if it was what I needed - would it include all of the headers with pin definitions and other utilities? I assume the ones I already have are AVR specific?

Build environments are not quite my area!

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

The part specific stuff is part of your project. Welcome to a world of pain! You should be able to find projects for command line use with a make file - none of this is specific for the raspi - anything for osx/linux will (should) work. Be sure to create a path to the compiler. Many projects are hosted on github,gitlab etc so having an idea about using git helps. Create a directory and then git clone https://github.com/blah....... grabs the project.

For example, I’m working with a Nordic arm device at the moment. The project is Espruino and it has a make file and all the required headers for the project. Assuming i had this on a raspi, all i’d need is arm-none-eabi-gcc and i’d be able to build it.

Be prepared for a steep learning curve!

Last Edited: Sat. Nov 17, 2018 - 01:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Welcome to a world of pain!

 

...

The project ... has a make file and all the required headers for the project. 

...

 

Be prepared for a steep learning curve!

 

OK, so it looks like the current version of Raspbian has an arm-none-eabi-gcc package. I've not installed it yet but it's there.

 

Next I've found the ASF standalone, which is also helpfully mirrored here:

 

https://github.com/marekr/asf/tr...

 

I've done some spelunking and found a samd10 folder with some register definition header files in it.

 

So (metaphorical fingers crossed): If I were to simply copy the contents of the samd10 folder into my Blink Project folder (Ultimately I'd put these in some global GCC include path?) it should build? Am I cutting too many corners?

 

EDIT: well, almost: https://community.atmel.com/comm...

 

annoyingly, the installation of AS7 on my work PC doesn't appear to have any options to build for ARM, only AVR. But I'm getting closer.

Last Edited: Mon. Nov 19, 2018 - 10:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you might want to see if the likes of platform-io run on the pi and whether it supports the SAMD10. This will take care of most of the evil. if not, you need to acquaint yourself with the concept of a 'make' file. Whilst you can have gcc compile and link each file, this becomes error prone and labourious when there more than a couple of files involved. Enter the 'make' file. This automates the process of building the code - like compiling only what needs to be compiled etc. It is effectively a programming language. You effectively program in all the steps and references needed for your project. Once done, you just type 'make' and it performs all the magic necessary to build your code.

 

This might give some hints:

https://engineer.john-whittingto...

 

All you need to know is on the interwebs.

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

Thank you Kartman.

 

  I think I've got enough to start breaking things with now!

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

I'm trying to load up vscode then platform io on the pi at the moment!

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

Kartman wrote:

I'm trying to load up vscode then platform io on the pi at the moment!

 

Good luck! I could probably make my life a lot easier by just doing it on a windows machine with AS7, but I like the idea of a pocket development environment that I can use anywhere, so I'm slowly building it out on my Pi. It does a great job for my AVR projects - I write the code on whatever I'm using (also means I can do development work on my iPad or phone). Everything goes in a Git repo on GitHub and I can pull it down on the Pi, build it and program the chip from the GPIO.

 

I want to start moving towards the M0 architecture as I think it will be more suitable for what I'm building, but I'm also trying to skip the development board step and go straight to custom boards which is definitely slowing me down. Your help is much appreciated.

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

I did manager to get Platform io going. Took a bit though. The first tutorial for loading vscode didn't work, so I googled some more and came across headmelt. This worked. Once vscode (or code-oss) was loaded, platform io was simples - it just took some time as network on the Pi is not the fastest, nor the storage.

 

Platform io supports the samd21, but I don't know what would be involved in getting samd10 working.

Last Edited: Thu. Nov 22, 2018 - 02:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Platform io supports the samd21, but I don't know what would be involved in getting samd10 working.

Well, I've managed to get a simple blink program to compile using just a Makefile and a handful of header files copied from the ASF standalone download.

I have no idea if it actually *works* yet as I haven't started on the OpenOCD part yet, but I have a .elf file to actually try with! #severalstepscloser

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

Sounds like progress!

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

Kartman wrote:
Sounds like progress!

So close :(

$ openocd -f interface/raspberrypi-native.cfg -c "transport select swd"</p>
<p>Info : only one transport option; autoselect 'jtag'<br />
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdi = 9<br />
Error: Can't change session's transport after the initial selection was made<br />
embedded:startup.tcl:21: Error:<br />
in procedure 'transport'<br />
in procedure 'ocd_bouncer'<br />
at file "embedded:startup.tcl", line 21

It's weird because $ openocd -c "transport list"

Lists swd as an available transport:

Open On-Chip Debugger 0.9.0 (2018-01-22-06:14)<br />
Licensed under GNU GPL v2<br />
For bug reports, read<br />
        http://openocd.org/doc/doxygen/bugs.html<br />
The following transports are available:<br />
        stlink_swim<br />
        hla_jtag<br />
        hla_swd<br />
        aice_jtag<br />
        swd<br />
        jtag 

Last Edited: Fri. Nov 23, 2018 - 10:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

do you need to run as sudo? ie sudo openocd .......

 

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

Kartman wrote:

do you need to run as sudo? ie sudo openocd .......

 

No, we'll, yes, not running as sudo gave an additional permission denied error, but I get the same error above with or without sudo.

I think JTAG is being selected automatically by the interface command (I made a .cfg with *just* interface BCM... and transport select send and get the same error" but I don't know nearly enough about openocd yet to know why.

I will keep hammering away at it when I get a few moments.

If I take out the transport line, it successfully starts up but looks very much like it's in JTAG mode, although when I tried to download it (gdb? I'm working from memory) I just get a timeout, but again, no idea whether the timeout is connecting to the openocd server or the chip.

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

MalphasWats wrote:
I will keep hammering away at it when I get a few moments.

 

Apologies for posting on an old thread, but I wanted to note my progress here over the weekend. The primary problem was that the version of OpenOCD in the raspbian repositories had been compiled without support for anything other than JTAG. After downloading the source and compiling it with all the extra options added in I was able to select SWD as the interface over GPIO.

 

After some initial false starts because I don't know how to count and also plugging jumper wires into the right holes even when I've counted right appears to be really hard for me...

 

Once I finally had everything wired up correctly, I got... NOTHING! Huzzah. No errors, just OpenOCD patiently waiting for an external connection. The default interface clock speed is 400KHz. I've never managed to get avrdude to run that fast so I set the speed to a conservative 10KHz and BINGO! OpenOCD connected to the chip via SWD and reported the correct part number! A few more tweaks and I had a blinking LED!

 

here is the openocd.cfg file that I used. It's a bit ratty and definitely WIP but it works and I like it:

 

interface bcm2835gpio                                                                                                  
#transport list
transport select swd

bcm2835gpio_swd_nums 24 23 
bcm2835gpio_trst_num 7 
bcm2835gpio_srst_num 18


 
set CHIPNAME at91samd10c14a
source [find target/at91samdXX.cfg]

adapter_khz 10

adapter_nsrst_delay 100
adapter_nsrst_assert_width 100

init
targets
#reset halt
at91samd bootloader 0
program blink.bin verify reset
shutdown

I've never been so pleased with myself as when I saw that little led blinking merrily away!

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

Ah! the sweet taste of success! Your SWD wiring is probably sub-optimal and along with the Pi's poor drive capability is probably limiting your SWD speed. Nevertheless, you've had some good progress. Onward and upward!