Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 34 of 34

Thread: wm8731+teensy schematics?

  1. #26
    Senior Member
    Join Date
    May 2016
    Posts
    108
    I am about to post a new thread about the I2C problem! I believe I might have gotten to the bottom of it, and if it is true, there is a bug in the Wire library! The WM8731 works very well with a T3.2 but fails completely on the T3.6 because the wiire.beginTransmission() function messes up the Read/Write bit in the I2C packet on a T3.6, but not on a T3.2! I'm about to start writing the post right now withl sample code and 'scope screenshots of the I2C packets on the two Teensies. By the way, bit-banged I2C works. Stay tuned - the new thread is on the way....

  2. #27
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,506
    Wow, I'd really like to see that code and give it a try here.

    If I miss that thread, please ping me directly (by email) with a link to the thread.

  3. #28
    I'm using Teensy 3.5, and for me the I2C side seems to be working perfectly. I'm using @blackaddr's BALibrary, and have commented in the error checking on the I2C transaction and every one seems to succeed. I'm using 4.7k pull-ups, which seems considerably higher than what most of the schematics are using (I would imagine that would make things worse though not better).

    Still no activity on the audio output pin though I tried @blackaddr suggestion of testing the audio bypass (using setAdcBypass() ), and I *was* able to see an analogue signal being passed through. Which suggests I2C is working fine (that's how ADC bypass is selected), and the analogue circuitry in the chip is working. The signal did seem slightly clipped, but maybe it doesn't get offset in bypass mode (if I offset the signal coming in, I was able to see the entire waveform).

    I've put a scope on the I2S clocks, the LRCLCK appears to be running at 44.1kHz, as expected, but the BCLCK, appears to be running at 2.8Mhz. This is x2 what I'd expect (44100*16*2=1.4Mhz). Have I set something up wrong? This would suggest the sample size 32bit samples? I haven't changed anything in the Teensy libs, (and this is a fresh install of Teensyduino 1.46 beta9, required to work with newest version of Arduino). Schematic and source code posted further up this thread.

    Here's what I'm seeing on the data lines

    Bit Clock at x2 expected speed
    Click image for larger version. 

Name:	BCLK.jpg 
Views:	1 
Size:	120.1 KB 
ID:	16075

    Left/Right Clock
    Click image for larger version. 

Name:	LRCLK.jpg 
Views:	2 
Size:	117.1 KB 
ID:	16076

    DACDAT (seems to be correctly reflecting that I'm only using 1 channel BUT the data stream seems to be half what I thought it would be, (e.g. a quarter of the cycle), which would be consistent with the bit clock being too fast.
    Click image for larger version. 

Name:	DACDAT.jpg 
Views:	1 
Size:	112.7 KB 
ID:	16077

    ADCDAT
    Click image for larger version. 

Name:	ADCDAT.jpg 
Views:	1 
Size:	126.7 KB 
ID:	16078
    Last edited by unicornpower; 03-05-2019 at 09:43 PM.

  4. #29
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,277
    The “high” bit clock of 2.8MHz is normal and ok. It allows 32 bit word transfers (64Bit per frame) but shorter words (24bit, 16bit) can be transported, though. The unneeded least significant bits are then set to zero. This is common standard nowadays and accepted or even required by most modern I2S hardware, including the WM8731 (following TI’s parametric table).

  5. #30
    Quote Originally Posted by Theremingenieur View Post
    The “high” bit clock of 2.8MHz is normal and ok. It allows 32 bit word transfers (64Bit per frame) but shorter words (24bit, 16bit) can be transported, though. The unneeded least significant bits are then set to zero. This is common standard nowadays and accepted or even required by most modern I2S hardware, including the WM8731 (following TI’s parametric table).
    Ah, that makes sense, thanks Theremingenieur! Seems a little wasteful, data-wise, but as long as it's to be expected.

    In that case though, I'm at a bit of a loss to explain why I don't see any output on the LOUT pin. As far as I can tell.

    • I2C is working - The Wire library is not returning errors, and I'm able to use it to set the codec into analogue bypass mode.
    • The analogue signal path seems correct - as shown by passing a signal though in bypass mode
    • All the I2S data getting to the chip seems correct (from what I can tell from the scope images above), and the chip is sending data back (via ADCDAT)


    I'm wondering if it's something silly like the volume is 0. As far as I can tell I'm setting the volume correctly. Are there any other settings I can try tweaking? This is using a Teensy 3.5 with a bespoke PCB to connect to the codec. Adding code again for completeness..

    Code:
    #include <Audio.h>
    #include <Wire.h>
    #include <SPI.h>
    #include <SD.h>
    #include <SerialFlash.h>
    
    #define ENABLE_CODEC
    
    //constexpr const int IN_BUILT_LED_PIN(13);
    
    #ifdef ENABLE_CODEC
    AudioInputI2S            audio_input;
    AudioOutputI2S           audio_output;
    //AudioInputAnalog        audio_input;
    //AudioOutputAnalog       audio_output;
    AudioControlWM8731       wm8731;
    #else // !ENABLE_CODE
    AudioInputAnalog        audio_input;
    AudioOutputAnalog       audio_output;
    #endif // !ENABLE_CODE
    
    AudioSynthWaveformSine   sine_generator;
    AudioConnection          patch_cord_1( sine_generator, 0, audio_output, 0 );
    
    
    void setup() 
    {  
    #ifdef ENABLE_CODEC
      wm8731.enable();
    #endif
      
      AudioMemory( 256 );
      
      sine_generator.amplitude(1.0f);
      sine_generator.frequency(440.0f);
    
    #ifdef ENABLE_CODEC
      wm8731.volume(1.0f);
    #endif
    
      Serial.begin(9600);
    
      Serial.println("Setup finished!");
    }
    
    void loop()
    {
      delay( 1000 );
      Serial.println("loop");
    }

  6. #31
    Unable to make any progress with my PCB, I went back to the drawing board (well, vero board), and built my circuit from scratch from the schematic I attached further up this thread. It worked! I2C transactions completing first time (no retries), and I2S data is correctly processed (I'm now seeing a sine wave on my scope). I'm yet to determine why this doesn't work on my PCB, but at least I know the schematic is correct.

    In this version I don't have any resistors in series on the data lines, maybe that was the issue on my PCB?

    Attachment 16113

  7. #32
    Hmm not sure why that image didn't work..

    Click image for larger version. 

Name:	455C7B1E-D229-46C5-80DA-7BC1EC4B3D0B.jpeg 
Views:	5 
Size:	108.9 KB 
ID:	16116

  8. #33
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,277
    The I2C bus is sensitive to wiring capacitance and inductance. Thus, things that work on one board layout will not forcibly work on a different board layout. Best practice is to plan pads or holes for the series SMD or through hole resistors, and to fit jumpers or 0R resistors in case they are not needed.

  9. #34
    Quote Originally Posted by Theremingenieur View Post
    The I2C bus is sensitive to wiring capacitance and inductance. Thus, things that work on one board layout will not forcibly work on a different board layout. Best practice is to plan pads or holes for the series SMD or through hole resistors, and to fit jumpers or 0R resistors in case they are not needed.
    Gotcha, thanks! I did actually add pads for smd resistors on the data lines on my PCB. I shall experiment with different resistances (including 0R).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •