Yes, perhaps just desolder one of the MAX31855's and go on...
Apart from a possible analog phenomenon, what still intrigues me is the fact that when you comment out the 6 'audio' lines, everything is working fine...maybe a software issue after all?
Anyway, good luck with your project!
Paul
Thank you PaulS!Originally Posted by PaulS
Yes, perhaps just desolder one of the MAX31855's and go on...
Apart from a possible analog phenomenon, what still intrigues me is the fact that when you comment out the 6 'audio' lines, everything is working fine...maybe a software issue after all?
Anyway, good luck with your project!
Paul
If anyone reading this finds a possible solution please write here.
Thank you to everyone who tried to help. I really appreciate it.
You mentioned that if you comment out those two lines (plus the ones that reference it), that you don't see the problem.
What happens if you only comment out one of them? That is, can you localize down to is it the Input one or the Output one, or either...
As far as my quick look goes, The I2S Input uses Pin 8 and output uses pin 7 and they both use/configure pins 20, 21, 23...
Again maybe can localize more if know if you can localize to using either or specific?
Commenting out just one of those two lines of code does not solve the problem. In fact, i think that when I comment out just the i2s2 lines the problem gets worse (more noise on the oled and the SCK led on pin 13 stops blinking after a while). This is what I noticed but it could be that it was just random timing with the more noise on the oled.
Bottom line is that if I comment out just one of the lines of code, the problem persists.
Do you have anything hooked up to the I2S pins? Or are they just floating?
Also wondering what all of the power usages are on your board. That is what all is hooked up to the 3.3v pins?
You have more ore less 250ma available.
So what is on the 3.3v? Display? (including backlight), MAX? Wireless? Could you finally be hitting a brown out?
In post #1 there is a link where you can see the actual PCB if you want.
Nothing is powered by the Teensy 3V3 pins. Everything that uses 3.3V is powered from a 3.3V 1A LDO.
The I2S pins are connected to a SGTL5000 chip. (Audio works fine.)
I disconnected the oled and all the other sensors (rpm, speed, gears, heart rate etc.) leaving just the GPS, NRF24, SGTL5000 ant Teensy powered and there were still problems on the SPI bus.
I will try to power the PCB from an external power source to see if the batteries are the problem. (Maybe they can not supply enough power?)
After some time testing everything I could think of, it turns out that there was some cross talk between the SCK traces and GND somewhere on the PCB.(This was hard to properly check beforehand considering I do not have a logic analyzer or an oscilloscope.) After cleaning everything up and checking everything that I could think of in this regard, the SPI bus is much happier. Now only very rarely I can see some noise on the Oled and the SPI bus does not stop working.
However, when I put my finger on the SCK side of the MAX31855 ICs I can see much noise on the screen and if I put a multi-meter (to see voltage) on the SCK pin, the SPI buss stops working. I think this means that I still have some cross talk somewhere.
Is the SPI buss supposed to stop working when I attach a multi-meter the the SCK pin?
After all the observations you shared, I now have a feeling that the power supply of the different parts may not be 'strong' enough, meaning not having a low-impedance path to GND or 3.3V. This will cause the whole chip to bounce under different mA loads.
For example: on the PCB layout I saw that pin VCC [2] of the nRF24L01 is not directly connected to the adjacent 3.3V plane but is connected by small traces to other components and via's and then to the 3.3V plane.
These small traces may cause a voltage drop on the actual chip 3.3V pin, making the chip unstable and prone to noise.
This was just a specific example I saw, but there may be more on the PCB.
I'm not saying this is THE issue with the board but it could be of influence.
For a quick test you could connect all 3.3V pins by a 'thick' external wire soldered to the Q1 output pin. Same for GND pins that are not directly connected to the GND plane.
And no, I normally do not expect the SPI bus to stop working when connecting a high-impedance digital voltmeter.
Hope this helps.
Paul
Thank you PaulS for your input.
I checked today the total power consumption of the board. With the Oled and shift lights connected and fully on, the PCB consumes about 490 mA maximum.
Still I will try to connect the 3.3V supply to the different components (including the 5V supply to the Teensy) by thick wires and see if this is the problem.
I designed the PCB to be 4 layers. Top - GND, Middle Top - GND, Middle Bottom - 3.3V, Bottom - GND. I used stitching vias for the GND planes and tried to get the traces as short and as thick as possible.
The example in the image you posted is just my way of getting the 3.3V supply of the NRF24 module trough the two capacitors on the top layer. It is a 1mm thick trace. (the small trace is just to connect the SMD pads. But the pads are not used since I soldered the NRF24 module using the pins.)
Do I need to make 3.3V pass trough the capacitors like in my design? Or is it ok to just connect the pin to 3.3V and the capacitors to 3.3V mounted as close to the pin as possible? (I don't know if I explain understandably what I want)
So I have done some more testing today.
- I soldered thick wires (from a CAT6a internet cable) from the 3.3V, 5V and GND pins of the LDOs to the PCB (3.3V pins of the NRF24, 5V and GND pins of the Teensy) to make sure that the traces are not the problem. There was no change. The problem is still there. (I think that the power traces are not the problem)
- I then tried desoldering everything that uses the SPI bus on the PCB. After I desoldered everything (just the empty traces were left) I wanted to check if the SPI bus stops working when I try to measure the SCK pin with a voltmeter. It stops working. I want to mention that after the SPI bus stops working, I have to reset the power in order to make it work again (turn off the PCB/Teensy and power it back on).
- The only time that I could measure the voltage on SCK with a voltmeter without problems was when I unplugged the Teensy from my PCB and powered it separately. Then I could measure SCK and everything worked. (I tried powering the Teensy directly from an external power source - like I did when it was unplugged - while it was still plugged in the PCB => the SPI bus stopped when I tried to measure voltage on SCK. So I am thinking that the PCB is somehow the problem.) I measured the resistance of the SPI traces on the PCB and I got 0 Ohm.
I will try next week to connect the Teensy pins one at a time to the PCB and see if I can figure out what is causing this.
Is there anything that could make the Teensy behave like this?
Well, this board is giving you a real fight...
Anyway, new information is welcome. Yes, perhaps there is an issue with the PCB.
Could you measure whether the SCK signal is shorting to other signals on the board? Especially to the I2S lines?
Paul
I will measure this.
One more thing: The SPI buss stops working only when I measure the SCK voltage directly on the pin of the Teensy. If I put the GND probe on a GND anywhere on the PCB and the *Plus* probe of the voltmeter on any other SCK pin on the PCB, the Teensy works fine. I don't know if this helps anyone identify the problem.
Huh? Now it's really becoming weird...
Some thoughts:
1. is there a soldering issue of pin 13?
2. could the onboard LED on pin 13 be too much load on the SCK signal?
3. are all the pins on Teensy 4.1 soldered correctly?
4. does any of the libraries drive the onboard LED without us knowing that?
Found this on the internet: The SCK for SPI is shared with the built in LED. This DOES NOT WORK for multi slave SPI application. You are not the only one with this problem...
Paul
1. Will check.
2. As far as the LED on pin 13 goes, I don't know if it is too much load for the SCK signal. Could the problem be just the LED? Because I could just desolder it and continue to use this SPI bus (changing it would mean to design another PCB and software). Or is it a problem with the internals of the Teensy in regard to this pin as SCK (meaning that there is nothing I can do to continue to use the SPI bus with multiple slaves and I have to use SPI1)? Maybe PaulStoffregen knows if there is a fix?
3. Will check.
4. The libraries that I use are:
<Audio.h>
<SPI.h>
<nRF24L01.h>
<RF24.h>
<Wire.h>
<U8g2lib.h>
<EEPROM.h>
<NMEAGPS.h>
<ResponsiveAnalogRead.h>
<Adafruit_MAX31855.h>
I don't think any of them use the LED.
SPI typically uses pin 13 on most/all Teensy boards, and we often drive multiple SPI devices on it.
And often times some comments/reviews may not be always totally accurate. As it was a T3.6 maybe they had an Audio adapter on the board, which uses Pin 13 for audio adapter...
Maybe you need to look at things, like are there Pull UP resistors on the devices. If so, how much? Maybe need to look at adding an external one...
If it was the data on MISO pin bad I would say you should check out those devices to make sure they are setup that the device does not screw it up. That is some devices don't work with others, like several displays don't, They may drive the MISO pin High and LOW, which screws up any other device that needs to talk back to the host. Many of the Adafruit boards have built in buffers and the like to fix them, but many other displays, like the ILI9488 and the like from Ebay or... do not.
Again sometimes hard to debug without having the hardware. If you have the extra parts and the like and can set it up. You might try breadboard or the like to see if you can get them to work that way, which would then point to your board.
Sorry I know not much help.
I have placed on the PCB pull ups on every CS line for the devices connected to SPI. 4.7kOhm. Is this too low or to high?
I will unplug the Teensy and connect one pin at a time with DuPont cables. Maybe this way I will see which is the pin that causes problems with SCK.
Thank you very much for the input. At this point, anything worth checking is a good thing
Hopefully today I will get around to check the soldering of the Teensy pins.
Until then, could someone tell me the exact steps/code lines I have to use to get the SCK pin from pin 13 to pin 27 of the Teensy 4.1? I tried SPI.setSCK(27) before and/or after SPI.begin() but with no success. I even tried just the u8g2 oled test example (without any of my original code) with the SPI.setSCK(27). Still no success.
I checked this forum for a bit but could not find a solution that works in this matter. I want to try this before I change the layout of my PCB. (If I change the SCK pin and the SPI bus still acts weird I know that is a PCB problem.)
On the forum there was some talk of SCK drive strength setting. How can I change that? (Maybe this is the problem.)
I would really appreciate it if someone could tell me the exact steps needed to change SCK from pin 13 to pin 27 or to change the SCK drive strength setting (this is a bit over my head). What files do I have to modify? What code do I have to write?
Thank you very much.
To use pin 27 for SPI, means to go over to using SPI1 and all of the pins associated with it.
That is pin 27 is not an alternate SCK pin for the SPI object. Unfortunately there are no alternate pins for most of the signals on the SPI object (Actual chip this is LPSPI4)
And from the SPI.cpp tables you see on T4.1 Note: 255 is not valid pin... Tables are max number of valid pins for all of the objects.
So again no alternates other than Hardware CS pin (1,2,3) says which PCS they are so all different.Code:12, 255, // MISO 11, 255, // MOSI 13, 255, // SCK 10, 37, 36, // CS 1, 2, 3,
For SPI1 (LPSPI1) you see:
Same order so MISO cab be 1 or 39 default 1Code:1, 39, 26, 255, 27, 255, 0, 38, 255, 1, 1, 0,
MOSI pin 26
SCK pin 27
CS can be 0 or 38 but both have same PCS value so only one of these can be used for Hardware CS in a sketch
Can also do for SPI2, but pins here are on bottom memory pads and SDIO pins, so...
This means that instead of using SPI.begin() I just use SPI1.begin()? Or do I have to do other changes too?
Thank you very much for clarifying this.
Everywhere that uses SPI. needs to use SPI1.
Luckily some libraries now allow you to pass in which SPI object by pointer or reference and use that instead of hard coded SPI.transfer(..) like calls.
So today I resoldered all the pins that I could think of on the Teensy and the PCB. This did not solve the SPI problem.
However, I now think that it is indeed a power issue.
Here is how I ended up at this conclusion:
1) I have the possibility to power the Teensy with 3.3V on the 3V3 pin or with 5V on the 5V pin. So far I have used 5V and the Teensy works, just having the SPI problem. When I power the Teensy with 3.3V on the 3V3 pin, the SPI bus does not work at all (sometimes the oled turns on but with the image distorted and shuts down after a few seconds.)
2) I tried soldering thicker wires to the SCK, MOSI, and MISO lines to make sure enough power gets to the modules. This made the problem worse. In fact, with the thicker wires, the Oled showed a lot of noise and sometimes did not turn on.
I just don't know why the Teensy/modules do not get enough power.
The problem is power related and since you are connecting several things together, I have to wonder about power distribution. Best is a star configuration where every device gets a dedicated wire pair (Vcc and ground) back to the voltage regulator.
I use a 4 layer PCB with the layers GND - GND - 3.3V - GND. The GND layers are stitched together with vias every 2.54mm (where possible). You can see the actual PCB layout here.
Every component has a via for power and another for GND as close as possible to the actual pin.
I have no idea why the components are not getting enough power. In fact I don't know if the actual modules are not getting enough power or the Teensy...
What is the power source coming in? If I remember you had a 1 Amp LDO 3.3v VR that was fed in from another 5v LDO VR? If I remember you mentioned something like 9V coming in?
I assume you are not saying a simple 9v Duracell or the like? Also what is the wiring that connect the source your board?
i.e - Could it simply be you are not providing enough juice?
The power source is now 2 or 3 battery cells (18650) connected in series (7.4V or 11.1V total) connected to the PCB with cat6a wires using this and this connectors. I also have access to a lab bench power source. Even connected to the lab bench power source (different voltages from 7V to 12V) with cat6a wires the problem persists. So I think that the actual power source is not the problem.
Could the cat6a wires be too thin? If so, what wire thickness should I use? The 3.3V goes to a 3.3V inner layer of the PCB. Maybe the vias are not sufficient connecting the LDO and the power layer?
As I mentioned in post #35, I already tried to connect thicker wires (cat6a) from the LDOs to the 3.3V, 5V, and GND pins. Could the inner 3.3V layer be the problem?
Also, I may have done a mistake in routing the 3.3V to which the pull up resistors are connected. (See the image below.) Basically, now 5V and 3.3V go to the Teensy. 5V directly to the 5V pin and 3.3V through the pull up resistors to the different I/O pins (sensors and CS pins). Could this be a problem?
Here is a picture of the power source I used (along with the total power consumption of the PCB)
Last edited by guzu; 08-20-2020 at 12:53 PM. Reason: Added power source image
Posting Permissions
Reply With Quote