Teensy 4.1 TDM issue

Status
Not open for further replies.
Do you think there's anything worthwhile to be learned by trying to reproduce the problem here on a CS42448 chip?

I do have 2 more bare CS42448 test PCBs, and plenty of parts to build them.... but time to do so is in short supply. Not sure if that's really worthwhile? Any thoughts?


Edit: now I see Frank offered to do the same test. Will hold off unless there's a need to repeat the test here.
 
This image (the circled part) does not look like transmission errors. The circled part shows linearly increasing (green) and decreasing (yellow) data. The probability of this happening randomly is pretty low. To me it looks like this is really transmitted data.
I've seen similar things when I wrote I2S code which was buggy.. that does not mean that the TDM has a bug. But it might be something something that causes a similar effect..
I use the same code on T4.0 and T4.1, and the same code for I2S and TDM. The only thing that changes is AudioOutputI2S / AudioOutputTDM and AudioConnection (0, 1 in I2S mode / 0, 2 in TDM mode).
I wrote approx. 30 new AudioLibrary objects for my needs, but use original I2S / TDM output objects that are not altered in any way.

Was the code you posted exactly the code you use? (That would be really important to know)

Yes, I tested the setup with my original code when I first noticed the issue, and then recorded the images with this basic code to make absolutely sure it's not the firmware / pots / switches that's causing the glitches.

Edit: Does not really sound like a hardware-issue, too.
Thanks Frank, not to me either :D
 
Do you have any extra 14 pin headers & 14 pin sockets? Maybe solder them together and plug them into the main 24 pin sockets, so then you can plug the Teensy 4.1 into *ONLY* the same 28 pins as Teensy 4.0 uses.

Teensy 4.0 and 4.1 are nearly identical hardware. So those extra 20 pins on your circuit board are the thing which is most likely different.

While it may involve some kludgey soldering to make an adaptor, just plugging the troublesome Teensy 4.1 into only the first 28 pins is relatively "easy", so why not give that a try?

Paul, I tried exactly that already with the same results... On the breadboard and on the PCB made only for testing purpose. I even connected only TDM and TFT pins to eliminate everything else, but the results were the same :(
 
Ok, i have the cs42488 here. Please post your HEX file! I can test, and perhaps confirm that. If i see the same effect, we'll know it's not your setup and I have some ideas how to debug that.

Thank you so much Paul and Frank for all your help. I will build and post the HEX file for testing, hopefully that will tell us somewhat more :)
 
Thank you so much Paul and Frank for all your help. I will build and post the HEX file for testing, hopefully that will tell us somewhat more :)


Still have to compare it with a T4.0 - but my scope shows this noise (spikes), too, an a T.41
Even without SPI.
 
But wait... now they are gone. Something is wrong.... not a joke. I replaced the 4.1 with a T4 - no spikes. A clean picture. Then I've put the T4.1 back in - clear Signal too.

Have NO idea what that was..
I'll try again, tomorrow.

At the moment it looks like that:
pic_17_1.png
 
Last edited:
Ok, found it.
I see the spikes when I disconnect the GND from the probes - Seems they had no good GND contact the first time with T4.1.

So.. no, I can't reproduce it.
 
pic_17_3.png
Just for the sake of completeness, here's how it looks with the GND problem. Looks surprisingly similar to the posted scope screenshots.
 
Hi, Frank. I checked multiple times for any grounding / ground loop issues and couldn't find any. It still doesn't explain why the same issues don't appear with I2S :rolleyes:
Anyway, I borrowed a second T4.1 to check if my sample is possibly defective and did a lot more testing today. Managed to isolate the main problem - I couldn't pinpoint it before because it's not a single issue, but a few issues appearing at the same time... And it has absolutely no connection with extra pins or the hardware around Teensy. I'll divide the conclusions into 3 categories, and then we'll hopefully be somewhat smarter together.

1) Memory issues
I use a memory buffer for partial screen redraw by pushing it to ILI9341 with a procedure similar to writeRect(). The array is declared in RAM2 at the beginning of the main .ino file:
Code:
uint16_t *scrBuff = new uint16_t[240*320];
Those horrible audio glitches I previously thought were SPI related are, in fact, mainly related to this buffer. When I move the buffer to ITCM
Code:
uint16_t scrBuff[240*320];
the issue is mainly gone and TDM now behaves more or less like I2S. But I really can't afford a 150kB buffer in precious RAM1 :( T4.0 works normally with this buffer in RAM2.

2) TDM issues
When I connected all 8 TDM channels instead of only 2, things got much better; but the glitches still appear on the oscilloscope and are clearly audible. Then I connected just 2 channels that are producing constant audio signal to these 8 TDM channels (audio 0 to TDM 0, audio 1 to TDM 2, audio 0 to TDM 4, audio 1 to TDM 6, and so on) and everything suddenly worked very well. As soon as I stop sending audio blocks to any of the connected TDM channels (or stop sending empty audio blocks to the mixer to save proc. usage), the glitches reappear. Again, this works perfectly well on T4.0.

3) ADC issues
I tested the complete ADC section (12 pots on Teensy ADC pins, 16 pots connected via HC4067 mux, 8 CV ins via AD7327 13-bit SPI ADC on SPI1) without Audio Library part, and it works exceptionally well: no analogReadAveraging or ResponsiveAnalogRead needed, rock solid 12-bit readings, fully satisfied. As soon as I involve Audio Library objects and start I2S or TDM output, ADC goes haywire and both 12-bit and 10-bit readings are all over the place :confused: Not by one or two bits, but seriously unstable and oscillating by four or five bits several times per second. I need to use analogReadAveraging(16) and ResponsiveAnalogRead with setActivityThreshold(16) to get barely acceptable results, but it slows the readings so much they are practically unusable :(
This unfortunately happens with T4.0 too, but external SPI ADC readings are not affected. I finally tested the situation where T4.0 is driving the TDM DAC and T4.1 is reading ADCs to make sure the external hardware and traces are not to blame, and as I suspected the readings were stable again. So, it has to be some internal IMXRT1062 glitch or a bug and I have no idea how to solve this :confused:
 
@Subfanatic - what happens if you run the code from msg #7? That code lacks the large buffer and any ADC use. It is the code I tested.

I don't know which code Frank ran for msg #31. Maybe it was similar to the code from msg #7 or msg #10, with the ADAU1966 stuff replaced by CS42448 initialization?

Details like exact code and how the hardware was actually connected might be pretty important here. I really hope you will show photos of the hardware during the test and the full code you actually ran.
 
I ran this:

Code:
#include <Audio.h>
#include <SPI.h>
#include <Wire.h>
#include "ILI9341_t3.h"

#define TFT_DC   29
#define TFT_CS   10

AudioOutputTDM           tdm;
AudioSynthWaveformSine   sine1;
AudioSynthWaveformSine   sine2;
AudioConnection          patchCord1(sine1, 0, tdm, 0);
AudioConnection          patchCord2(sine2, 0, tdm, 2);

[COLOR=#ff0000]AudioControlCS42448      cs42448_1;[/COLOR]

ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC);

elapsedMillis fps1;

void setup()
{    
    AudioNoInterrupts();
    Serial.begin(9600);
    delay(300);
[COLOR=#ff0000]    cs42448_1.enable();
    cs42448_1.volume(1.0f);[/COLOR]
    AudioMemory(64);
    analogReadRes(10);
    analogReadAveraging(12);
    sine1.frequency(20.f);
    sine2.frequency(10.f);
    sine1.amplitude(0.95f);
    sine2.amplitude(0.95f);
    tft.begin();
    tft.setRotation(3);
    tft.fillScreen(ILI9341_BLACK);
    AudioInterrupts();
}

void loop()
{
    tft.drawRect(20, 20, 50, 50, ILI9341_GREEN);
    if (fps1 > 1000)
    {
        fps1 = 0;
        Serial.printf("CPU: %f (%f)\n", AudioProcessorUsage(), AudioProcessorUsageMax());
        Serial.printf("MEM: %i (%i)\n\n", AudioMemoryUsage(), AudioMemoryUsageMax());
    }
}
 
Can you post your HEX (+used sourcecode) file for the CS42448? I can use it and compare. It should show the same problem, right?
 
Status
Not open for further replies.
Back
Top