SPI port issues- Raspberry Pi


Raspberry Pi Particle-agent 0.2.4 (current)
Tests done using Siglent Digital scope.
I have found on my Raspi 3 B+ that you can use the SPI port within your particle-agent program, but the Particle SPI documentation has a number of errors, and it won’t work if you follow the docs as written.

  1. You must use either spi.begin(CE0) [which uses CE0/GPIO8 as -CS] or spi1.begin(CE1) [which uses CE1/GPIO7 as -CS] If you use SPI.begin() [as shown in docs] , the compiler throws no errors, the firmware flashes successfully (according to status line) , but program doesn’t work. More seriously, after that, if you then try to download corrected/different firmware, or even Tinker, from the online IDE, the firmware download process will indicate success- but whatever code is running on the agent stays intact.The way you can tell that firmware has not been successfully flashed, is that you will NOT see the Raspi go offline momentarily, in the status bar at the bottom right of the Build screen, as you will when firmware flashes OK.
    The only way I could overcome this was to unclaim the device from the Particle console, then run particle-agent setup from Raspi command line.The particle-agent setup alone won’t succeed, unless you first unclaim the device.

  2. The statement in the docs that your code must toggle the -CS line associated with the SPI port, by using digitalWrite(CE0,LOW), digitalWrite(CE0,HIGH) is FALSE. The SPI.transfer() function does it automatically for CE0, and SPI1.transfer() does it for CE1. Note- this functionality is odd- you do need to use the digitalWrite() commands for normal Arduino code, and I suspect you need to do it if you are using Particle photon,electron, etc.

  3. The docs say the default SPI clock speed on the Raspi is 4 MHZ. This is correct. However, the SPI.setClockSpeed() doesn’t work, either in the value,scale method (12,MHZ) or the direct method (12000000). The SPI.setClockDivider does work, but only slows the clock way down from 4 MHz. I measured 135 Khz on SPI_CLOCK_DIV4 and 4 Khz on SPI_CLOCK_DIV16. I know the SPI speed can certainly be set much higher than 4 MHz from other languages, such as Python.

  4. SPI.setBitOrder function doesn’t change it from MSB first (default) to LSB first, if you give it the LSBFIRST parameter. It also put the Raspi in the state in which no further firmware flashes work (like 1 above).

Ialso tried these tests on a Raspi ZeroW and 2 B, with similar problems


Thanks for the detailed report, can you file an issue on the GitHub repo?

This will probably get more attention from the devs than a forum post.


Thanks ScruffR. It hadn’t occurred to me yet, to post it as an issue on Github, but I’ll do so.