Particle Boron New Haven OLED Display Issue


#4

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!


#5

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?


#6

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(){

Serial.begin(9600);

delay(1000);

pinMode(DISP_CS, OUTPUT);
pinMode(SPI_DATA_CMD, OUTPUT);

digitalWrite(SPI_DATA_CMD, LOW);

delay(2000);

Serial.println("starting u8g2");

u8g2.begin();

Serial.println("Line 90");

}

void loop(void){

Serial.println("Line 103");

clrBuf;

Serial.println("Line 109");

font14B;

Serial.println("Line 113");

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

Serial.println("Line 117");

sndBuf;

Serial.println("Line 121");

}

Any additional thoughts? Thank you for your help!


#7

#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>


#8

Hi,

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!


#9

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?


#10

Hi,

Thank you for pointing out SYSTEM_THREAD. I’ll check that out.

https://www.newhavendisplay.com/nhd31225664ucy2-p-3537.html this is the display that is being used.


#11

@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.


#12

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.


#13

@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!


#14

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.


#15

@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.


#16

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: https://www.adafruit.com/product/3727 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.

-Matt


#17

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.


#18

Could it be that you are running into this issue?


#19

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.


#20

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


#21

Making some progress in identifying it. So far I’ve been able to tell that the SOS is caused by a NULL pointer reference. There’s a function pointer (cb) kept in the u8g2 struct that gets overwritten by ClearDisplay() causing it to be set to NULL. Still digging further.


#22

I’m kind of stumped at this point. Sometimes cb ends up null after ClearDisplay() does a memset operation. Sometimes it does not. Even when it does not, when u8g2->cb->update_dimension() is called, it causes the SOS. I thought at first this was a simple memory overrun, but it’s bigger than that.

This code is extremely confusing to me. Functions are abstracted out two or three levels, making it nearly impossible to follow, even in the debugger. For instance, I don’t actually know where the code for u8g2->cb->update_dimension() resides or what it does due to all the typedefs, conditional compilation, and apparently some machine generated code.

I’ve lost two days on it. Time to put it aside for now and look for a simpler library. I might pick this back up in the future. Heck, I’d be willing to send the author a free Argon if he’d be willing to fix it.


#23

@picsil They might do it if you send them one. I seem to remember extending that same offer and then communication fell off. Maybe they have more time now to take a look. I seem to remember that they were traveling before or something like that. Thanks for keeping us up to date!