Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 15 of 15

Thread: Is there a pin-conflict between USB-host and Serial1 on Teensy-3.6?

  1. #1

    Is there a pin-conflict between USB-host and Serial1 on Teensy-3.6?

    Hi,

    I was using Serial1 (pin 0,1) as MIDI input with a Teensy audio card and it worked nicely on my Teensy-3.6. Than I added a USB connector to the Teensy-3.6 (4(5) pins on the PCB). This does also work, but it seems that my (DIN-serial-)MIDI input is not working anymore... very strange. Is there a pin conflict or do I broke up something?

    TIA, Holger

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    AFAIK they are independent - not seen any reason or note that they could conflict. They are independent parts of the processor.

    Any chance of a bridge to host GND pin or other in the soldering?

    Does the previously working code - with no USB Host lib/activity still fail? If the USB Host port is not activated or used and Serial1_Midi still fails - it would suggest the added pin connects are to blame.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,596
    They are independent. I built this board some time ago to test Serial1-Serial5 together with USBHost_t36 MIDI and usbMIDI (to the PC). All are able to work simultaneously.

    Click image for larger version. 

Name:	midi.jpeg 
Views:	21 
Size:	152.9 KB 
ID:	13997

    You can find some of the test code in File > Examples > USBHost_t36 > MIDI > Interface_16x16.
    Last edited by PaulStoffregen; 06-12-2018 at 12:05 PM. Reason: typo

  4. #4
    Thanks @defragster and @PaulStoffregen,

    older code or code with disabled USBHost_t36 is also not working anymore... I will try to check with a scope at evening - perhaps also replacing the opto.

    Holger

  5. #5
    Ok, it seems that I have killed the serial input of pin 0 on my Teensy-3.6. Don't know how... very strange. My MIDI circuit is the one from https://www.pjrc.com/teensy/td_libs_MIDI.html and it worked for a long time. After connecting the USB-host port I got this problem. The PCB looks fine and I cannot imagine that I have made any shortcut while testing. I will try to use another serial port.

    BTW: The Teensy-3.5 has no USB-host port, am I right?

    Regards, Holger

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    Correct - Only the T_3.6 has the Processor hardware for USB Host. The T_3.5 shares the same PCB - but 2 of those pins have alternate functions.

    Bummer on pin function loss. T_3.6 won't take much over 3.3V - did it get zapped?

  7. #7
    Quote Originally Posted by defragster View Post
    Correct - Only the T_3.6 has the Processor hardware for USB Host. The T_3.5 shares the same PCB - but 2 of those pins have alternate functions.
    Ah, ok, thanks!

    Quote Originally Posted by defragster View Post
    Bummer on pin function loss. T_3.6 won't take much over 3.3V - did it get zapped?
    Yes, it's a pitty. The really worse thing is, that it took much time to find the real problem. Only a comparison with my T_3.5 showed up that the input is broken. But this can happen during development... I have to learn to be more careful and to buy more spare parts - and there are some more serial ports on my T_3.6 I can break

    Regards, Holger

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    The back of the T_3.5 versus the T_3.6 card details the function of those pin holes for alternate function. On the PCB the only diff { aside from MCU's label } is the added components for USB Host support on the T_3.6, that are empty on the T_3.5.

    If you buy one - it will leave you at a bad time … If you buy two or more - you'll never break one … working for me so far.

    Hopefully what ever broke that pin didn't do more damage that will show up later.

  9. #9
    Quote Originally Posted by defragster View Post
    Hopefully what ever broke that pin didn't do more damage that will show up later.
    Got my new T_3.6 and soldered the pin rows and USB port. My MicroDexed is working again :-)

    So I tried the same code on my old T_3.6: Serial is broken (also Serial2,3,4), USB or other things also seems to be broken. After getting some MIDI events via USB, the sound calculation stops - seems like a full stop of the T_3.6. That's the luck of a developer

    But I am glad that it works again on my new one!

    Regards, Holger

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    … Good News … Bad News. Glad you are back in business.

  11. #11
    Bad news...

    The new T_3.6 worked 10 days ago (both inputs: MIDI and USB). After trying yesterday I have the same problems as with the broken one before: No input from MIDI, no input from USB. This is very strange because the same code works on the T_3.5 (with Serial-MIDI-Input) without problems.

    I really don't know what I am doing wrong. The (old) T_3.6 worked until I started to solder the external USB-Host-Interface. The same with the new one. First it runs but after some days it seems to be broken. Has anybody an idea what I am doing wrong?

    This is really bad. The T_3.[56] has such a friendly community, good support and a really good software stack, but for my project (MicroDexed) I cannot try with a new T_3.6 a week as long I don't know why I seem to kill the uC. I think I will give the ESP32 a try :-/

    Regards, Holger

  12. #12
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,440
    Can only guess without good photos of the solder situation. The Host USB has 5V near Pin 1.

    T_3.6 coming up on 2 years out? Not seen any reason to believe it would just fail without cause.

  13. #13
    Quote Originally Posted by defragster View Post
    Can only guess without good photos of the solder situation. The Host USB has 5V near Pin 1.

    T_3.6 coming up on 2 years out? Not seen any reason to believe it would just fail without cause.
    I will try to make photos the next days... I am sure that it is my fault, but do not have any idea what I have done wrong

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,596
    Very hard to guess what's going wrong here. It could be a simple hardware issue like a wire shorted between pins.

    But it could be a tough software problem which only looks like hardware failing. The simplest way to check is by loading a very basic test program onto the suspected-bad hardware. For example, something like this:

    Code:
    void setup() {
      Serial1.begin(9600);
    }
    void loop() {
      Serial1.println("Hello World");
      delay(100);
    }
    Then try to receive the data with a USB-serial cable or even another known-good Teensy running File > Examples > Teensy > USB_Serial > USBtoSerial.

    I see your project has a huge amount of code. A very common problem involves buffer overflows, where code writes beyond the end of an array. These often manifest in strange ways that look like flaky hardware failure, because the results depend on whatever happened to be placed in memory right after the array and how other code actually uses it.

    You're also using 2 interrupts which call queue_midi_event(). Are you sure queue_midi_event() is thread-safe to call from an interrupt? I see it does printing to Serial and calls a bunch of other code, which ultimately seems to access quite a bit of static data. This sort of code is almost never safe to use from interrupts, unless you design is very carefully with volatile variables and proper disable of interrupts when accessing shared data. I tried to explain these sorts of issues on the IntervalTimer page, where is says in red "Advanced programming is required".

    As a first step, I'd suggest using something like elapsedMillis which you check from your main loop to schedule stuff. Avoid interrupts. They make everything so much harder and almost always lead to very confusing bugs when used with anything but the simplest possible code.

  15. #15
    Hi Paul,

    many thanks for your quick response!

    Quote Originally Posted by PaulStoffregen View Post
    Very hard to guess what's going wrong here. It could be a simple hardware issue like a wire shorted between pins.

    But it could be a tough software problem which only looks like hardware failing. The simplest way to check is by loading a very basic test program onto the suspected-bad hardware. For example, something like this:

    Code:
    void setup() {
      Serial1.begin(9600);
    }
    void loop() {
      Serial1.println("Hello World");
      delay(100);
    }
    Then try to receive the data with a USB-serial cable or even another known-good Teensy running File > Examples > Teensy > USB_Serial > USBtoSerial.
    I tried some (own written) simple MIDI test programs and they failed on Serial and USB. But I will try again with a smaller program and a USB-serial-dongle.

    Quote Originally Posted by PaulStoffregen View Post
    I see your project has a huge amount of code. A very common problem involves buffer overflows, where code writes beyond the end of an array. These often manifest in strange ways that look like flaky hardware failure, because the results depend on whatever happened to be placed in memory right after the array and how other code actually uses it.
    The main code is running on some other systems (arm/i384/amd64) without problems. Only my "glue" code may be the source of pain...

    Quote Originally Posted by PaulStoffregen View Post
    You're also using 2 interrupts which call queue_midi_event(). Are you sure queue_midi_event() is thread-safe to call from an interrupt? I see it does printing to Serial and calls a bunch of other code, which ultimately seems to access quite a bit of static data. This sort of code is almost never safe to use from interrupts, unless you design is very carefully with volatile variables and proper disable of interrupts when accessing shared data. I tried to explain these sorts of issues on the
    IntervalTimer page, where is says in red "Advanced programming is required".

    As a first step, I'd suggest using something like elapsedMillis which you check from your main loop to schedule stuff. Avoid interrupts. They make everything so much harder and almost always lead to very confusing bugs when used with anything but the simplest possible code.
    If you mean the two IntervalTimers as interrupt sources: They are only used when starting the MIDI test events in a test function when I don't have a MIDI keyboard for generating events. Normaly I compile without #define TEST_NOTE, so the interrupts are not used.

    Why I am thinking it is a hardware problem: The same code (without using IntervalTimer) is running on the T_3.5 without problems... and it worked for about 10 minutes on a T_3.6 some days ago...

    Thanks again && regards, Holger

Posting Permissions

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