Particle Boron New Haven OLED Display Issue

Hello All,

I’ve been having some issues with getting a display to work with a Particle Boron. I started with some more advanced code, but after having issues I decided to go back to the basics to see if there is just something that is being missed.

This is the code that I have been flashing:

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

U8G2_SSD1322_NHD_256X64_F_4W_SW_SPI u8g2(U8G2_R0, /* clock=*/ D13, /* data=*/ D12, /* cs=*/ D14, /* dc=*/ D15); // Enable U8G2_16BIT in u8g2.h
//U8G2_SSD1322_NHD_256X64_F_4W_HW_SPI u8g2(U8G2_R0, / cs=/ 10, / dc=/ 9, / reset=*/ 8); // Enable U8G2_16BIT in u8g2.h

#define DISP_CS D14
#define SPI_DATA_CMD D15
#define SPI_SCK D13
#define SPI_MOSI D12

void setup(void) {

pinMode (DISP_CS , OUTPUT);


digitalWrite(SPI_DATA_CMD , LOW);


void loop(void) {
u8g2.clearBuffer(); // clear the internal memory
u8g2.setFont(u8g2_font_ncenB08_tr); // choose a suitable font
u8g2.drawStr(0,10,"Hello World!"); // write something to the internal memory
u8g2.sendBuffer(); // transfer internal memory to the display

It is able to flash successfully but on start up on the Boron goes into a hard fault with single red led error.

I really appreciate any help or thoughts as to what might be going on. Thank you!

You should probably use HW_SPI and go with the pins marked SCK & MO instead of SW_SPI.

@shonky2 I have had issues with SPI when porting libraries. If you are able, I would find the SPI_write() and SPI_read() functions and replace with a straightforward SPI.beginTransaction(); with settings required SPI.transfer(); and ended by SPI.endTransaction();
I would also add you need to run this on 0.9.0 as there were issues with SPI before that Device OS.

1 Like

Ok, I have changed to the HW SPI and I’m still running into the same issues.

@armor It looks like when this library was ported the SPI_write and SPI_read have already been replace with what you recommended.

I appreciate any more ideas! Thank you!

I suggest you post all your code. It depends what the SPIRead and SPIWrite were actually replaced with. Also, can you confirm you are on 0.9.0?

Hello All,

I’ve made some progress today. No more red light so it seems as thought the firmware is running. I’ve been running the following code and it is printing the serial lines up until 113 then stops. Also tried drawLine and that does the same thing. Never makes it to print line 117.

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

#define clrBuf            u8g2.clearBuffer()
#define sndBuf                      u8g2.sendBuffer()

#define setBottom                u8g2.setFontPosBottom()
#define wrStr(x, y, b)            u8g2.drawStr(x, y, b)
#define wrLine(x, y, x1, y1)   u8g2.drawLine(x, y, x1, y1)

#define font14B                    u8g2.setFont(u8g2_font_helvB14_tr)

#define DISP_CS D15
#define SPI_DATA_CMD D16

U8G2_SSD1322_NHD_256X64_F_4W_HW_SPI u8g2(U8G2_R0, DISP_CS, SPI_DATA_CMD); // Enable U8G2_16BIT in u8g2.h

void setup(){




digitalWrite(SPI_DATA_CMD, LOW);


Serial.println("starting u8g2");


Serial.println("Line 90");


void loop(void){

Serial.println("Line 103");


Serial.println("Line 109");


Serial.println("Line 113");

wrStr(10,20,"This is a test");

Serial.println("Line 117");


Serial.println("Line 121");


Any additional thoughts? Thank you for your help!

#define DISP_CS D15
#define SPI_DATA_CMD D16

Can you confirm your physical wiring - the hardware default for CS is A2. Try using DISP_CS A2 instead.
I would also confirm SPI_DATA_CMD - DC/RS on the board - try moving this to D5 say. Have you looked at the Boron datasheet - I don’t have one myself, not sure what pin D15 and D16 are possibly A4 and A3.

Not clear why you are using macros for the u8g2 methods. Try substituting u8g2.drawStr(10,20,“Hello”); in place of wrStr() etc.

You do not #include <SPI.h> and could try without <Arduino.h>

1 Like


I appreciate your help. I’ve gone through a multitude of different configurations including the ones that you suggested. I think that there is some issue in the library that was ported that I just haven’t been able to track down. I’m seeing that it takes about 12 seconds for the Boron to start up from power on which would leave the display blank for that long with no feedback to the user. I think what I’ll end up doing is paring an small Arduino with the display because I know that the original library works on Arduino and then I will have the boron send the display buffer information to the Arduino. This will also give the ability for the display to show a message during a system update cycle as well.

I appreciate the brainstorming. Thank you!

This is (most likely) because you have not specified SYSTEM_THREAD(ENABLE) so user code will not run until a cloud connection is established. As for the library, can you provide a link to the exact display you are using?


Thank you for pointing out SYSTEM_THREAD. I’ll check that out. this is the display that is being used.

@shonky2, looking at your code, I am perplexed as to why the D15 and D16 pins are considered valid. As @armor already pointed out, the valid pins are D0-D8 and A0-A5. The “default” hardware SPI pins are shows on the actual board (MIso, MOsi, SCK) and you can chose the CS and DATA_CMD pins within the valid range of pins such a CS = A5 and DATA_CMD = D5 for example.

1 Like

This is what @armor already pointed out.
I’d also suggest you stick with the pin labels printed on the silk screen on the device.


@peekay123 @ScruffR Thank you all for re-stating. I apologize @armor that I dismissed it earlier. I kept referring back to the datasheet and was looking at the pin number and in my mind was connecting that to the Dpin because I had seen other code where the variables were getting defined and Dpin now realizing the difference I feel like an absolute goof. I really appreciate all of you helping. I will test later on and let you know the results.

Thank you!


Hi All,

So I tried this and now I’m running back into the issue of the Red led single flash SOS.

Not sure what would be next.

@shonky2 have you had any more success with this library? I’m running into the exact problem you are on the boron (single flash SOS) using an SH1106 display.

hi @picsil unfortunately we were never able to resolve the issue. I had even asked the library creator for any direction, but no luck there since they didn’t have the hardware to test on. What we ended up doing was using the I2C bus on the Boron to communicate to a Adafruit ItsyBitsy M0 and are using SPI on the ItsyBitsy board to drive the screen. It has been working great for our application and allows us to still display some messages when the boron is updating and allows us to display a splash screen before the Boron is up. From my experience Boron takes about 6 secs to fire up and display a screen message. Going this route we were able to get the splash screen up in 1 sec. Please let me know if you do ever resolve as I would still be curious as to the fix, but for us integrating the 2nd board added some functionality that turned out to be useful for interacting with a display. Link to other board used: Looks like currently out of stock at Adafruit, but there are other distributors that have them in stock. Please let me know if you have any other questions.


Thanks Matt. I’m attempting to get the debugger working so I can step through the code. Not having much luck so far with the debugger in Workbench, but that’s another issue. If I find a solution I’ll post it to the community.

1 Like

Could it be that you are running into this issue?


Thank you @ScruffR, that was exactly the problem. Not sure why I didn’t find that post in my search, but thanks. Now that the debugger is working, I’m looking into the u8g2 crash.

1 Like

@picsil I’m looking forward to what you uncover.