Different SPI behavior on Nano Connect RP2040 between Arduino MBED core and Pico Core? #813
Description
This is gonna be a weird one, I expect.
This is on version 2.5.0
I have some code that uses an SX1276 lora module on a nano connect. With the normal arduino mbed core, it succeeds, if i swap it to yours, it fails to initialize the lora chip. (This is platformio so literally just commenting/uncommenting the build_core setting and having it recompile/reupload).
I have tracked this down to SPI transfers seemingly giving wonky results.
I have removed all of the code, and this is what remains:
#include <SPI.h>
void setup() {
// perform reset of chip
pinMode(9, OUTPUT);
digitalWrite(9, HIGH);
delay(100);
digitalWrite(9, LOW);
delay(100);
digitalWrite(9, HIGH);
delay(100);
// setup CS
pinMode(10, OUTPUT);
digitalWrite(10, HIGH);
SPI.begin();
}
void loop() {
digitalWrite(10, LOW);
SPI.beginTransaction(SPISettings(4E6, MSBFIRST, SPI_MODE0));
uint8_t address = 0x42;
SPI.transfer(address);
uint8_t value = 0;
uint8_t response = SPI.transfer(value);
Serial.print("Read of version returned ");
Serial.println(response, HEX);
SPI.endTransaction();
digitalWrite(10, HIGH);
delay(2000);
}
A couple things: It could theoretically be the reset, but that would be even weirder, as i woudl expect that code to "just work". The delays here are far above the minimum (and the arduino core works fine with any delay > the manufacturer minimum. So 10 would be fine).
I will scope it all tomorrow.
More importantly the SPI transfers give different results. On the arduino mbed core version you will see the following printed:
Read of version returned 12
Read of version returned 12
Read of version returned 12
Read of version returned 12
Read of version returned 12
...
and on your core you will see:
Read of version returned 0
Read of version returned 0
Read of version returned 0
Read of version returned 0
Read of version returned 0
...
0x12 is the correct answer. I tried going through the mbed SPI code to see if there were any obvious differences, but it's too many layers to make obvious sense of.
Like I said, happy to go generate some scope traces, but was wondering if there is something obviously wrong.
I also tried translating it directly into pico sdk code and using that from the arduino setup/loop function - same result - gives back 0's, and claims to have read/written the right number of bytes.
(assuming i got it right).
That looks STH like this (i borrowed from their spi master example)
<setup code>
// Enable SPI 0 at 4 MHz and connect to GPIOs
spi_init(spi_default, 4000 * 1000);
gpio_set_function(12, GPIO_FUNC_SPI);
gpio_set_function(11, GPIO_FUNC_SPI);
gpio_set_function(13, GPIO_FUNC_SPI);
gpio_set_function(10, GPIO_FUNC_SPI);
// Make the SPI pins available to picotool
bi_decl(bi_4pins_with_func(12, 11, 13, 10, GPIO_FUNC_SPI));
...
<loop code>
uint8_t address = 0x42;
int bytes;
bytes = spi_write_blocking(spi_default, &address, 1);
Serial.print("Wrote ");
Serial.print(bytes, DEC);
Serial.println(" bytes");
uint8_t value = 0;
uint8_t response;
bytes = spi_read_blocking(spi_default, value, &response, 1);
Serial.print("Read ");
Serial.print(bytes, DEC);
Serial.println(" bytes");
Serial.print("Read of version returned ");
Serial.println(response, HEX);
digitalWrite(10, HIGH);
delay(2000);