Looking to debug the qwiic connection on a new sparkfun redboard turbo, have tried all the demo sketches and cannot get the micro oled to come to life. Have tried the micro oled on an older sparkfun redboard and it works via that qwiic shield etc… So I know the micro oled display is good, just cannot seem to get it to function on the new redboard turbo. have checked and updated all the samd libraries I know of etc… The redboard turbo does appear to function with other non qwiic demo sketches.
If anyone has any suggestions for debugging this setup to prove out the qwiic connection on the redboard turbo please send them my way. using an imac for the arduino IDE v1.8.9
as an update to this problem, I see no clock signals on the SDA and SCL pins on the redboard turbo on my o’scope whereas I do see these on the older sparkfun redboard & qwiic shield, any suggestions to bring these pins alive?
Calling the specific pins for SDA and SCL in the Wire.begin(); function should fix the problem here so I am not certain what is going on with this board and the Turbo. I’m going to do some more digging in the library to see what might be causing the issue. I’ll update you on anything I figure out.
I have a strange update to this issue. I was trying to nail down when or if an update to the [Micro OLED Arduino Library broke anything and surprisingly got it working with the Turbo after rolling back to a previous version (I started with [v1.2.0 as that is when SAMD support was added) using the Library Manager tool and then when I updated to the latest version, v1.2.7, all of a sudden it sprang to life.
Hello Mark, no other qwiic boards to try here, plus, in attempting to roll back to an earlier micro oled library I am now receiving the following error; Invalid library found in /Users/jj/Documents/Arduino/libraries/SparkFun_Micro_OLED_Arduino_Library-master: no headers files (.h) found in /Users/jj/Documents/Arduino/libraries/SparkFun_Micro_OLED_Arduino_Library-master
Hmm…How are you selecting the library version? I would recommend uninstalling the library through the Arduino Library Manager tool and then re-installing and see if that helps. Do you by chance have another microcontroller you can test the Qwiic OLED on to rule that out as the culprit here?
Hi Mark, the qwiic oled works on an older sparkfun redboard (non turbo samd etc…) as seen in my first posting, so that part is Ok on the older microcontroller, I’ll work on the library manger tool to see if I can clear up that error message…
Hello Mark, I first used the library manager screen to try an roll back to an earlier version, there is no way to remove a library via that screen that I can find, somewhat different compared to the Boards manager screen. I cannot seem to get rid of that warning message regarding no header files found…
Thanks for clarifying what method you were using and that the OLED is working properly.
Let’s try manually removing/locating the library files. If you’re not familiar with how to do that, you’ll need to locate your Arduino/Libraries folder. Depending on which version and install of Arduino you are using, on Windows, it usually is in your User/Documents folder under Arduino/Libraries. You can also navigate to the folder the example is hosted in by either using the shortcut “CTRL+K” or opening the “Sketch” dropdown menu and selecting “Show Sketch Folder”. After you have opened the sketch folder, navigate to either the “SparkFun_Micro_OLED_Breakout” folder or your general “libraries” folder.
Next, check the “SRC” folder in the “SparkFun_Micro_OLED_Breakout” folder to see if the header and C++ files are there. If they are present but that error is still popping up, just remove them from the “Libraries” folder either by deleting or just moving them to a temporary home on your desktop. After that, go back to the Library Manager tool in Arduino and install the library. It should say the library is not installed and will let you choose which version to install. Just try installing the latest version again and retry with the Turbo. Let me know if you still are getting errors or if Arduino is still claiming the library is installed and we can keep working on this issue. Screenshots of the error(s) and your Library Manager showing the library would be helpful here too.
Ok, I went ahead and removed all the Sparkfun Micro Oled folders/files I could find in the /Libraries folder, that made the missing header file messages go away. Reloaded the Sparkfun Micro Oled library as seen in the attached screen shot.
Looks like it is at the latest version 1.2.7, both .h and C++ files are seen in the folders. Opened the MicroOLED_Demo_I2C.ino example from the Arduino / Files/Examples/Sparkfun Micro OLED Breakout library that was just installed. Compiled and uploaded the new sketch and still no output from the micro oled, no errors either.
Interesting observation, both the SCL & SDA lines are low when the IDE shows “Done Uploading”, however, the SDA line goes high when using the Wire.begin(20,21); statement with the 20,21 pin assignments typed in. Still no clock signals, but just the SDA line goes and stays high. Without the pin assignments as in Wire.begin(); both SCL & SDA stay low.
Huh, you’ve got me stumped here. I’m starting to think something may be up with your RedBoard Turbo. Try running an I2C scan like [this on your Turbo with the Micro OLED attached to the Qwiic port and see if it recognizes the device on the bus.](Arduino Playground - I2cScanner)
Unfortunately I’m thinking RMA for the turbo board, I did try the I2C scanner, interesting results, got stuck on the very first address = 1 at the statement “error = Wire.endTransmission();”, never finished / returned from that call to .endTransmission() and the sketch hangs at that statement never incrementing the address++ and never exiting out or finishing, just hangs forever until I stop it.
It definitely sounds like something is wrong with the hardware/software for the I2C bus on your Turbo. Thanks for sticking with the troubleshooting steps here. If you purchased the Turbo directly from SparkFun, please fill out the form on [this page and in the “Why do you want an RMA?” box, fill in a brief description of the issue and include a link to this post and we’ll follow up with further instructions on that process.](Return Policy - SparkFun Electronics)
Hi Mark, I filled out the RMA but I have found something that I believe was the culprit this whole time and may need a word of caution for those folks that wish to purchase and mount the turbo board to the DEV-11235 Arduino & Breadboard holder. I used the two phillips head screws that came with the DEV-11235 and mounted the turbo with these at the top left and bottom right mounting holes when viewing the turbo board with the USB/power lines at the top, facing up, and the qwiic and SPI headers facing down.
Mind you these screws were not torqued in any fashion, just enough to hold turbo board in place. I looked at the turbo board under a large magnifier and observed some circuit traces imprinted on the turbo board very close to the mounting hole location on the bottom right, just to the right of the 6 SPI header pins. When I removed the phillips head screw I can see a bit of the red coating had come off from the slight friction of the screw touching the board exposing some copper traces that surround this mounting hole. As you might have already guessed, the micro oled display now works via the qwiic connector. The mounting screw appears to have shorted out these traces, unknown what they are, but the effect was to disable the I2C bus. I’d like to suggest that sparkfun may want to consider an advisory for future redboard turbo owners to exercise caution when using any kind of metal screw in that specific mounting hole location.
Unknown at this point if any permanent damage was caused by the aforementioned phillips head screw contacting the copper traces.
Well, that would explain it. The screw probably had “grounded out” the SCL trace by exposing a bit of the copper in that trace under the solder mask. It should not have broken anything since the I2C master is only trying to drive that line LOW but it may have slightly damaged the trace to the point where it may fail in the future. If you’re uncertain about the performance of the I2C bus on your Turbo going forward, we can still help you out via an RMA ticket but it should not be necessary.
I would recommend putting screws on the opposite mounting holes or using some non-conductive washers to isolate that mounting hole from the SCL trace. I’m glad we finally figured out what was causing the issue, though. Let us know if you run into any other problems or have any questions about these or another of our products, tutorials or example code and we would be happy to help as much as we can.
