U8G2 HW SPI breaks after update from 2.6.2 to 3.6.0

[mattthegamer463]

Hi,

I've been using Arduino Pico 2.6.2 for a long time but recently updated it to current (3.6.0) because I saw there are some new features , but now my SPI LCD won't work. My Hello World code is below:

#include <Arduino.h>
#include <U8g2lib.h>

#include <SPI.h>

//doesn't work
U8G2_ST7586S_ERC240160_F_4W_HW_SPI u8g2(U8G2_R0, /* cs=*/ 17, /* dc=*/ 20, /* reset=*/ 21);

//works
//U8G2_ST7586S_ERC240160_F_4W_SW_SPI u8g2(U8G2_R0, /*clock*/ 18,/*data*/ 19, /* cs=*/ 17, /* dc=*/ 20, /* reset=*/ 21);

void setup(void) {
 
  u8g2.begin();
  
}
void loop(void) {
  u8g2.clearBuffer();					// clear the internal memory
  u8g2.setFont(u8g2_font_logisoso16_tf);
  u8g2.drawStr(5,20,"Hello World!");	// write something to the internal memory
  u8g2.sendBuffer();					// transfer internal memory to the display
  delay(1000);  
} 

Declaring as software SPI works, but the refresh rate is very low. Declaring HW SPI like I used to and the screen has no response. If I compile using Arduino Mbed, HW SPI works, but my other projects use RPi_Pico_TimerInterrupt which Mbed errors on, saying it's not supported.

I'm using the default SPI0 and default pins, and it always worked on 2.6.2 so I'm not sure what's happened. Hopefully someone has an insight.

Thanks,

• Matt

[earlephilhower]

Sorry, but you're going to have to provide more info to get help. What exactly is happening? Is it hanging? Report device not found? Any other debug info? (Turn on Tools->Debug Port->Serial and then Tools->Debug Level->SPI to capture).

You can also try bisecting things by moving somewhere between 2.6.2 and 3.6.0 (i.e. does 3.0.0 work but 3.1.0 fail) which would narrow things down tremendously.

[mattthegamer463]

Hi Earl,

Here's the very start of initialization on 3.3.0

Now, I was having a hard time getting the serial monitor to capture the start of initialization because the port is occupied. So I tried moving the display begin() function call to the loop instead of setup, so it would repeat it. This made the display start working. I tried adding a delay before the begin() in setup, to see if that helped. It didn't. What does make it work however, is running the begin() function twice.

I've updated to 3.6.0 and it's working as long as I do the initialization twice.

I did manage to get the initialization:

SPI::begin(0), rx=16, cs=17, sck=18, tx=19
SPI::beginTransaction(clk=4000000, bo=MSB)
SPI: initting SPI
SPI: actual baudrate=4000000
SPI: IRQ masks before = 00000000 00000000 00000000 00000000
SPI: IRQ masks after = 00000000 00000000 00000000 00000000
SPI::endTransaction()
SPI: IRQ masks = 00000000 00000000 00000000 00000000
SPI::beginTransaction(clk=8000000, bo=MSB)
SPI: deinitting currently active SPI
SPI: initting SPI
SPI: actual baudrate=8000000
SPI: IRQ masks before = 00000000 00000000 00000000 00000000
SPI: IRQ masks after = 00000000 00000000 00000000 00000000
SPI::endTransaction()
SPI: IRQ masks = 00000000 00000000 00000000 00000000
SPI::beginTransaction(clk=8000000, bo=MSB)
SPI: Reusing existing initted SPI
SPI: IRQ masks before = 00000000 00000000 00000000 00000000
SPI: IRQ masks after = 00000000 00000000 00000000 00000000
SPI::transfer(01), cpol=1, cpha=1
SPI: read back 00
SPI::transfer(11), cpol=1, cpha=1
SPI: read back 00

The SPI Frequency is default, the clock speed is 133MHz. I tried downclocking to 50MHz and the logic analyzer showed a change, but it didn't fix it.

It's interesting if there is a 1 bit shift causing all the data sent during init to be wrong, but when it's run a 2nd time it doesn't have that problem.

[earlephilhower]

Looking at your close-up first image, you can clearly see the clock-stretched first (invalid?) bit. I wonder if there's a race condition somewhere in the library or SPI code in the SDK 1.5.1 vs 1.5.0 WRT the device enable/disable stuff they added.

The SDK codepath is called 2x because it starts up at default 4MHZ and then is changed to 8MHZ by the GFX library. The core SPI class is smart enough not to reset the SPI device if all settings are the same between transactions, so we can try setting the defaults here to 8MHZ and see if avoiding that clock speed change avoids the extra clock transition.

Edit

arduino-pico/libraries/SPI/src/SPI.cpp

Lines 322 to 324 in 41b0686

	// Give a default config in case user doesn't use beginTransaction
	beginTransaction(_spis);
	endTransaction();

to

_spis = SPISettings(8000000, MSBFIRST, SPI_MODE0);
beginTransaction(_spis);
endTransaction();

[mattthegamer463]

Hi Earl,

I think I implemented the change correctly, the file was in C:\Users\mattt\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\3.6.0\libraries\SPI\src

Logic analyzer show it's still running at the same clock speed but there is still the bit shift during init.

EDIT:

Initializing twice no longer works either, LA shows the 1 bit shift is occuring for both init calls now.

EDIT 2:

If I undo the spi.cpp change you recommended, the 2nd init starts to work again.

[earlephilhower]

Gotta say that I'm pretty stumped now. No issues with other SPI users so there still must be something specific about this use case. I'm thinking it might not be the protocol so much as something else here.

SPI interfaces normally have a CS, yes? Are you sure the CS pin is disabled until the GFX lib starts communicating? There might always be some glitchiness as the SPI unit comes online and takes over the pins, but it would be ignored since CS would be deasserted until a real command comes. Can you capture the CS pin as well and see that it's disabled until the 1st valid bit of data?

[mattthegamer463]

Hi Earl,

In the LA captures, line D0 is the CS pin for the device. It's GP17 on the Pi which is "SPI0 CSn" and I don't touch it, the SPI and LCD lib are doing whatever they wish with it when I call the begin() function. It doesn't look like it's doing anything weird as far as I can see from the captures.

I greatly appreciate your help with this, since it is working by calling the initialization twice, I'm happy to call this fixed and chalk up the root cause to the gremlins.