Forum Rule: Always post complete source code & details to reproduce any issue!
Page 8 of 8 FirstFirst ... 6 7 8
Results 176 to 181 of 181

Thread: Teensy 4.0 Breakout Kit

  1. #176
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,312
    GOOD NEWS - I HAVE MY USB BACK with the TallDog T4 direct pinned breakout I assembled.

    I was thinking if I put flux on my desolder braid I could pull off all the solder and lift the Flex cable - erroneous thought!

    I went over it twice - all I ended up with was a small bit of solder in the braid and even nicer looking solder to reflow on the top of the cable!

    So rather than get medieval - with too much flux and more effort and a solder sucker. I set the DMM range to test 200, then 2K then 20K ohms and the only sign of connectivity was IIRC 12K on the USB pads - which may be normal. I touched Flex solder to adjacent PAD, then again Flex solder to PCB pins direct for Zero Ohms and then adjacent for overscale at 20K!

    So it was time to give it a try to see if I pulled out any excess solder that was bridging and so far so good! T4 powered up running old sketch.

    My IDE is BUSY doing a Board Mgr update so I used the last compiled logger_RawWrite.hex from TEMP dir and it was set for USB. I now get light on my USB Dongle and a functional test of the SD card file writing to not one but both of the SD cards here. And it kept the RTC time - as I had to upload with TyCommander that doesn't yet know how to set the time.

    - still "Mount: Failed with rc=FR_DISK_ERR." on the TD_Breakout to same SD card plugged in. I put that same SD card onto PJRC Beta breakout PCB and the test runs perfectly fine with a button press to upload the same code. Return card to TD_Breakout and push button to upload fresh and _ERR again

    Note: I get the same 'Mount: Failed with rc=FR_DISK_ERR.' when I power the T4 with NO SD card present on both TallDog and PJRC breakout - is there a chance messed up the SD socket taking off the cover? The card detect switch or something? Or maybe some of the prior efforts { when the T4 went Dormant } with bridged pads damaged a pin in T4 needed to make this work?

    I'll try PinTest'ing tomorrow and see if the 'Pin On' when it should not be happens again showing T4 damage now that I can't detect any bridges/shorts between pins. But USB WORKS! I'll try some Hard drives that run faster - not enough power without adding a powered HUB - even for 2 SSD's tried - and that needs code change.

  2. #177
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,918
    Well have some good news and some bad news.

    Using the following approach:

    Code:
    Put Kapton tape above the sdio pads covering the holes, if any,  and put another piece above the D+/D- pads.  
    I started by only soldering the 1 sdio pin and getting that lined up best I could but and heres the catch. 
    I moved the cable down a hair leaving a bit of the pads exposed so I could solder over it.  
    Then I soldered the D+/D- pins (I pre tined the pads).  
    Then I finished soldering the rest of the SDIO pads.  Then checked for shorts and corrected as necessary. 
    Then ran the blink any pin sketch - so far only 1 pad doesn't work on the SDIO, pin 38 but it does blink on the connector side.
    Not sure of the usb pins yet.
    Going to trouble shoot a little more but there has to be a better way.

  3. #178
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,312
    Just got as far as putting PWM to test on 34,35,36 that are Jumpered to 37,38,39 for digital read testing on the PCB edge where I put a female header.

    I run a pass of that then swap the halves to go the other way. Does this make sense as explained?

    This seems to show my T4 has a defective pin #36 - suspicion is the early shorted solder on the Flex Zapped the pin to some degree. Bottom of post shows array reorder to match pin jumper change and it runs with results noted there.
    {edit} : perhaps a short to GND on #36 where soldered to Teensy - but that would give more consistent behavior - if it could ever get to a '1' value ... AFAIK?
    {edit 2} : opps - #36 short would be to 3V3 or D- but not to GND. If D- is really going negative that would explain it as Teensy pins don't like negative voltage?

    @loglow :: if this is what happened this any many other issues would be resolved if GND and 3V3 were not carried on the FLEX cable as indicated in p#175 ( or #173 ) - and the Flex and PCB layout were changed to put those BLANK pad spaces to minimizes soldering defects as per p#175 where GND and 3V3 were routed directly from elsewhere on the PCB. This makes the FLEX asymmetric and also means the Flex could not go to a daughter board for USB and SDIO without taking GND and 3V3 ( if that were an idea ).
    > In the process after losing USB I did learn something useful : after soldering the Flex to PCB a pass with desolder braid ( holding flux ) pulled off excess solder and restored USB, but that won't apply when the Flex is fed to the soldered connector.

    I am seeing unexpected results at various frequencies on one pin. As coded below the PWM frequency is 2M and I see this:
    Code:
    Compile Time:: T:\tCode\T4\TallDog_SDIOpinTest\TallDog_SDIOpinTest.ino Sep 18 2019 01:33:40
    0 Cnt=1999826 PWM out =34 Dig Read =37
    1 Cnt=1999966 PWM out =35 Dig Read =38
    2 Cnt=274722 PWM out =36 Dig Read =39
    
    3 Cnt=1999938 PWM out =37 Dig Read =34
    4 Cnt=1999462 PWM out =38 Dig Read =35
    5 Cnt=64130 PWM out =39 Dig Read =36
    
    0 Cnt=1998504 PWM out =34 Dig Read =37
    1 Cnt=1999966 PWM out =35 Dig Read =38
    2 Cnt=150820 PWM out =36 Dig Read =39
    
    3 Cnt=1999962 PWM out =37 Dig Read =34
    4 Cnt=1999968 PWM out =38 Dig Read =35
    
    >> HUNG HERE?  It is stuck!!!!
    Output this run stopped as above in what would have been :: PWM out =39 Dig Read =36
    Code:
          while ( 0 == digitalReadFast( pinsSDIO[nn] ) );
          while ( digitalReadFast( pinsSDIO[nn] ) );
    If it is Pin #36 at fault then the digital read is in a failed state ????
    > With the Handy PCB switch a power cycle the next time PAUSED on the first not second instance of that combination, then while I was typing this line it continued a full iteration and then stopped on that combo the next pass.
    > It does not always HANG - but always seems to miscount where pin #36 is involved


    Here is the code { with Edit to show while wait for 0 versus 1 as shown at post end}:
    Code:
    void setup() {
      Serial.begin(115200);
      while (!Serial && millis() < 4000 );
      Serial.println("Compile Time:: " __FILE__ " " __DATE__ " " __TIME__);
    }
    
    uint32_t cnt = 0;
    void loop() {
      cnt++;
      sdioTestPWM( cnt );
    }
    
    
    elapsedMillis emiWait;
    //uint32_t pinsSDIO[9] = { 34, 35, 36, 37, 38, 39, 34, 35, 36 };
    uint32_t pinsSDIO[9] = { 34, 35, 36, 37, 39, 38, 34, 35, 36 };
    void sdioTestPWM( uint32_t cnt) {
      int ii, mm, nn;
      if ( cnt % 2 ) mm = 0;
      else mm = 3;
      for ( ii = mm; ii < mm + 3; ii++ ) {
        nn = ii + 3;
        //    pinMode( pinsSDIO[ii], INPUT_DISABLE); // Not required - pin state set on analogWrite
        pinMode( pinsSDIO[nn], INPUT);
      }
    
      for ( ii = mm; ii < mm + 3; ii++ ) {
        nn = ii + 3;
        //    analogWriteFrequency( pinsSDIO[ii], (nn + (cnt % 4)) * 100000 ); // Similar results on changing or other frequencies
        analogWriteFrequency( pinsSDIO[ii], 2000000 );
        analogWrite( pinsSDIO[ii], 128 );
        delayMicroseconds( 4);
        uint32_t pCnt = 0, Cnt0 = 0, Cnt1 = 0;
        while ( 0 == digitalReadFast( pinsSDIO[nn] ) );
        while ( digitalReadFast( pinsSDIO[nn] ) );
        emiWait = 0;
        while ( emiWait < 500 ) {
          while ( 0 == digitalReadFast( pinsSDIO[nn] ) ) Cnt0++;
          while ( digitalReadFast( pinsSDIO[nn] ) ) Cnt1++;
          pCnt++;
        }
        Serial.print(ii);
        Serial.print(" Cnt=");
        Serial.print(pCnt * 2);
        Serial.print(" PWM out =");
        Serial.print(pinsSDIO[ii]);
        Serial.print(" Dig Read =");
        Serial.print(pinsSDIO[nn]);
        Serial.print(" Cnt0's=");
        Serial.print(Cnt0);
        Serial.print(" Cnt1's=");
        Serial.print(Cnt1);
        Serial.println();
      }
      Serial.println();
    }
    Other times it runs as it should but that same pin combo does not yield the set frequency - some HIGH some LOW:
    Code:
    0 Cnt=1999308 PWM out =34 Dig Read =37
    1 Cnt=1999968 PWM out =35 Dig Read =38
    2 Cnt=2015180 PWM out =36 Dig Read =39
    
    3 Cnt=1999964 PWM out =37 Dig Read =34
    4 Cnt=1999968 PWM out =38 Dig Read =35
    5 Cnt=843326 PWM out =39 Dig Read =36
    
    0 Cnt=1999528 PWM out =34 Dig Read =37
    1 Cnt=1999968 PWM out =35 Dig Read =38
    2 Cnt=2299240 PWM out =36 Dig Read =39
    
    3 Cnt=1999964 PWM out =37 Dig Read =34
    4 Cnt=1999968 PWM out =38 Dig Read =35
    5 Cnt=924524 PWM out =39 Dig Read =36
    I see this given this cable and array swap of 39, 38:: uint32_t pinsSDIO[9] = { 34, 35, 36, 37, 39, 38, 34, 35, 36 };
    Code:
    0 Cnt=1999928 PWM out =34 Dig Read =37
    1 Cnt=1999966 PWM out =35 Dig Read =39
    2 Cnt=3443452 PWM out =36 Dig Read =38
    
    3 Cnt=1999964 PWM out =37 Dig Read =34
    4 Cnt=1999968 PWM out =39 Dig Read =35
    5 Cnt=474784 PWM out =38 Dig Read =36
    Not sure what this adds - but a quick code add shows it is not spending as much time in the while wait for Zero's as it does waiting for One's - so the pin won't drive HIGH too well:
    Code:
    4 Cnt=1999962 PWM out =39 Dig Read =35 Cnt0's=14999223 Cnt1's=13397242
    5 Cnt=1645562 PWM out =38 Dig Read =36 Cnt0's=3613763 Cnt1's=23983135
    
    Very Curious count result was just noticed:
    Code:
    1 Cnt=1999964 PWM out =35 Dig Read =39 Cnt0's=14997380 Cnt1's=13398915
    2 Cnt=618470 PWM out =36 Dig Read =38 Cnt0's=3554 Cnt1's=29171653
    Last edited by defragster; Today at 09:43 AM.

  4. #179
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,292
    @defragster - As usual you do a far better and thorough testing than I have been able (and most of the time willing) to do!

    Great stuff..

    EDIT: FYI - as I mentioned I will see if I can solder on jumpers to USB pads, to see if I can at least test to see if I get any USB output...

    As you can see I did not do an overly clean removal of the flex cable:
    Click image for larger version. 

Name:	IMG_0883.jpg 
Views:	6 
Size:	93.7 KB 
ID:	17622
    Last edited by KurtE; Today at 02:07 PM.

  5. #180
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,918
    @defragster - I agree whole heartedly with @KurtE.

  6. #181
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,292
    Update to previous post, where I showed the bottom pads that were either the pads were ripped off or parts of flex cable still sort of there.

    I did quickly just put some solder over the USB pads, cut a female/female connector in half and soldered on, and then plugged them into top of USB+- pins of breakout board. I used extra long pins on the board so I can do stuff with both top and bottom...

    I then compiled the USBHost_t36 mouse example and plugged in a mouse and ...

    Code:
    USB Host Testing
    960
    *** Device HID1 46d:c063 - connected ***
      manufacturer: DELL
      product: DELL USB Laser Mouse
    *** HID Device Mouse1 46d:c063 - connected ***
      manufacturer: DELL
      product: DELL USB Laser Mouse
    Mouse: buttons = 1,  mouseX = 0,  mouseY = 0,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 0,  mouseY = 1,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 2,  mouseY = 6,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 1,  mouseY = 4,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 2,  mouseY = 4,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 1,  mouseY = 4,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 1,  mouseY = 3,  wheel = 0,  wheelH = 0
    Mouse: buttons = 1,  mouseX = 1,  mouseY = 3,  wheel = 0,  wheelH = 0
    Mouse: buttons = 0,  mouseX = 0,  mouseY = 0,  wheel = 0,  wheelH = 0
    Mouse: buttons = 0,  mouseX = -1,  mouseY = 1,  wheel = 0,  wheelH = 0
    Mouse: buttons = 0,  mouseX = -8,  mouseY = 2,  wheel = 0,  wheelH = 0
    ...
    It ain't pretty but at least the USB part is working now. So probably implies I soldered the really really small chip correctly.

Posting Permissions

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