Hey,
Can someone confirm that SPI is working on the samr21-xpro board?
I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different.
It would help me to know that it works on samr21-xpro.
I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem
OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today.
Yes I know, I changed it to make it work 
(SPI1)
Ah, _now_ it makes sense. Thanks for letting me know.
That leaves me with my own SPI problem. On my Autonomo I can't get
it to work. It is working with Arduino, but with RIOT (under construction) it's
not 
Autonomo uses samd21 CPU? You use same driver as samr21? What's your problem? Are you sure your SPI Slave chip is working correctly?
This very same setup works perfectly with Arduino. It is a SAMD21 on a Autonomo (very much like Arduine Zero). It has a 16Mb "serial flash" chip on it.
I started with the code from cpu/samd21 that was developed for the samr21-xpro board.
The "only" thing I had to change is the pins for the SPI. And with the pins I also had to change the SERCOM, the PADs and the pin MUX. And yes, I checked the SS pin (and all other pins) over and over.
So far I was able to get UART and I2C working. But for more than a week now I am stuck at SPI. I use the tests/periph_spi test program.
�main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)
RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started
> �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)
RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started
> help Command Description
Hey,
Hey,
It drives me nuts. Any hint is greatly appreciated.
Do you have a logic analyzer?
No, I don't have one. At some point I shall buy one, I guess. But that introduces new challenges. The SPI signals are not easily accessible.
Hey,
It drives me nuts. Any hint is greatly appreciated.
Do you have a logic analyzer?
No, I don't have one. At some point I shall buy one, I guess. But that introduces new challenges. The SPI signals are not easily accessible.
I've made good experiences with the cheap Saleae ones (I've been using cheap remakes from ebay like [1]).
It's easy to hook them up between MCU and SPI-device, and they come with simple but usable Linux software that can decode SPI signals. Tremendously useful for spotting timing errors ...
Kaspar
Hi Kees,
stupid question: How do you know SPI is not working? "GPIO_1090536471" was a formatting bug, compare:
https://github.com/RIOT-OS/RIOT/pull/5619
Would you try to initialize an other pin as CS line? If I see it correctly you decided for PA23. Maybe just try it with PB2 (in case you don't use it for other things).
Best Peter
I didn't know this exist! [1] but I'll vote for it. First, you need to know if something goes on SPI MOSI line and if timing is ok.
I made a local change to the format of that message, using %lx because that way I can look
up the address in the data sheet. The last two hex digits are good enough for me to see that 17 is 23.
But yeah, the GPIO_PIN() is perhaps a better idea.
I am using an Atmel ICE that connects via openocd. I can single step through the code with gdb (from Emacs). That way I can confirm that the CS line is indeed the expected PA23.
Hey,
It drives me nuts. Any hint is greatly appreciated.
Do you have a logic analyzer?
No, I don't have one. At some point I shall buy one, I guess. But that introduces new challenges. The SPI signals are not easily accessible.
I've made good experiences with the cheap Saleae ones (I've been using cheap remakes from ebay like [1]).
It's easy to hook them up between MCU and SPI-device, and they come with simple but usable Linux software that can decode SPI signals. Tremendously useful for spotting timing errors ...
Ah, thanks for the pointer. I'll have a look.
It was staring me in the face but I didn't see it.
It was a wrong mux for the MOSI pin. I finally found by single stepping
through the Arduino code. Stupid mistake that took me almost a week
Here's proof.
> init_master 0 0 23 SPI_0 successfully initialized as master, cs: GPIO_0x41004417, mode: 0, speed: 2 > > send Transfered 5 bytes: MOSI 0 1 2 3 4 0x9f 0x00 0x00 0x00 0x00 ?? ?? ?? ?? ??
MISO 0 1 2 3 4 0xff 0x1f 0x26 0x00 0x01 ?? ?? & ?? ??
Anyway, I have to tidy up the code and then I consider the Autonomo ready for RIOT.