Reset due to (motor-) EMI?

Status
Not open for further replies.

Joegi

Well-known member
Hi, I'm having a strange issue with a Teensy LC. When I start a dc-motor which is connected via a POLOLU DRV8838 driver (VCC=3.3V (from pin 17); Vm = 5V (from USB)) the Teensy often (not always) resets. It first seemed that the program pin is sensitive to the EMI caused by the motor (with no interference suppression), because when I connected the Prog pin to 3.3V it ran without resetting for a while. Then I removed that cable and tried to get rid of the resets by using capacitors between gnd and prog and alternatively between prog and 3.3V, but that had no success. Then I decided to solder in a (longer) cable between 3.3v and prog again and cut it for programming and connect it to properly run the code. Strangely since then the Teensy WITH PROG CONNECTED TO 3.3V still resets after the motor has been started AND RELOADS THE CODE (when the Teensy loader is active)! To see if there could be a high current issue that leads to a reset I added a cheap USB voltage measuring tool (I don't have an oscilloscope). This shows ~250mA for a very short time when the motor starts and then 130mA.
Any idea how to solve this issue? A software solution would be nice! ;)
Thanks for the answers in advance!
 
Oops, I just remember that I once tried to upload code while the cable between prog and 3.3V was connected. That would have created a short that might have killed the pin which would explain that it now still "jumps" into programming mode when the motor is started. So maybe it is not a good idea to connect 3.3v to prog. Any idea how to solve the EMI prog pin issue?
If not I would have to exchange the Teensy with an ARDUINO micro (but then had to redesign and 3d-print the housing again).
 
In casual testing it seemed in general the T_3.2 was not as sensitive to noise as T_LC. IIRC that was striking a piezo based lighter unit near both powered devices. Swapping a T_3.2 for the T_LC should be a simple swap in same case?

The T_3.2 would be an upgrade and hopefully fully compatible with the use case. And if ordered from OSHPark only $17 for a purple T_3.2. The T_3.2 also shows 250 mA on 3.3V pin versus the T_LC's 100 mA - not sure if that could have any effect.
 
In casual testing it seemed in general the T_3.2 was not as sensitive to noise as T_LC. IIRC that was striking a piezo based lighter unit near both powered devices. Swapping a T_3.2 for the T_LC should be a simple swap in same case?

The T_3.2 would be an upgrade and hopefully fully compatible with the use case. And if ordered from OSHPark only $17 for a purple T_3.2. The T_3.2 also shows 250 mA on 3.3V pin versus the T_LC's 100 mA - not sure if that could have any effect.

Thanks for the hint, I will order and try a Teensy 3.2! Alternatively I might try to check with another Teensy LC, I have lying around, if connecting a 4k resistor between prog and 3.3V would help.
 
if you connect program pin directly to 3.3v it would be wise to put a series resister to prevent a short when programming, whats your powersupply?
 
if you connect program pin directly to 3.3v it would be wise to put a series resister to prevent a short when programming, whats your powersupply?
As powersupply I tried a husb-hub (with extra power supply) a wall wart and a power bank.
 
does the motor have a separate supply? if you’re powering it off the same USB source as teensy that quick draw could be normal to reset. motors draw alot of current
 
does the motor have a separate supply? if you’re powering it off the same USB source as teensy that quick draw could be normal to reset. motors draw alot of current

I'm using the same power source for the motor, but when it runs it only draws 110mA (@ PWM-value of 150) as I wrote previously. I now will do tests on a breadboard with a Teensy LC with a 4k resistor to "prog" and if that does not help I will try an Arduino Micro I have lying around.
 
I'm using the same power source for the motor, but when it runs it only draws 110mA (@ PWM-value of 150) as I wrote previously. I now will do tests on a breadboard with a Teensy LC with a 4k resistor to "prog" and if that does not help I will try an Arduino Micro I have lying around.

Motors have various "current draw" situations. The highest current draw of a motor is when it's stationary and starting or when it's been jammed stuck in a stall. I would retry your testing with a separate power supply for the motor. The teensys tend to be very robust in my experience. Are you taking your 5v supply for your motor from the 5vUSB pin on the teensy? You don't have an oscilloscope to verify but I would put money on your motor pulling much more than your 250mA on startup (depending on the refresh rate of your power monitor the motor could potentially pull 500mA or more for less than a few milliseconds but it's been averaged out by your meter). This extra current draw would be enough to kill the USB communication briefly which could stop your program or produce weird USB results from your connected PC.

What motor are you using and can you provide a wiring diagram of your setup?
 
Motors have various "current draw" situations. The highest current draw of a motor is when it's stationary and starting or when it's been jammed stuck in a stall. I would retry your testing with a separate power supply for the motor. The teensys tend to be very robust in my experience. Are you taking your 5v supply for your motor from the 5vUSB pin on the teensy? You don't have an oscilloscope to verify but I would put money on your motor pulling much more than your 250mA on startup (depending on the refresh rate of your power monitor the motor could potentially pull 500mA or more for less than a few milliseconds but it's been averaged out by your meter). This extra current draw would be enough to kill the USB communication briefly which could stop your program or produce weird USB results from your connected PC.

What motor are you using and can you provide a wiring diagram of your setup?

Yes, i'm taking the 5V for the motor from the Teensy's 5V pin. The thing is that when I first connected 3.3V to prog I ran code that switched the motor on for 3 secs and then off for 3 secs and so on and it ran without any issue for about one minute (and then I stopped it)! At the moment I'm at work and can't do any testing, but in four to five hours I will do those tests!
 
Yes, i'm taking the 5V for the motor from the Teensy's 5V pin. The thing is that when I first connected 3.3V to prog I ran code that switched the motor on for 3 secs and then off for 3 secs and so on and it ran without any issue for about one minute (and then I stopped it)! At the moment I'm at work and can't do any testing, but in four to five hours I will do those tests!

Personally I think your 3v3-prog situation is a red herring. Again, the teensy is very robust in it's own right. I believe it's far more likely to be your power usage/motor draw causing issues on the power lines and usb cable than anything to do with the program line on the teensy. I may be wrong but gut instinct.

We'll be able to provide better support if you can provide a schematic, images of your layout and the spec sheet for the motor.

First thing to try is separate power supplies. Power the teensy via USB and the motor separately from one of your other options. Try and follow the pololu wiring diagram as;
https://a.pololu-files.com/picture/0J5753.1200.jpg?50c496833e2581e265001cafd9085ba4

If you still have issues then we can go from there,

Good luck!
 
Personally I think your 3v3-prog situation is a red herring. Again, the teensy is very robust in it's own right. I believe it's far more likely to be your power usage/motor draw causing issues on the power lines and usb cable than anything to do with the program line on the teensy. I may be wrong but gut instinct.

We'll be able to provide better support if you can provide a schematic, images of your layout and the spec sheet for the motor.

First thing to try is separate power supplies. Power the teensy via USB and the motor separately from one of your other options. Try and follow the pololu wiring diagram as;
https://a.pololu-files.com/picture/0J5753.1200.jpg?50c496833e2581e265001cafd9085ba4

If you still have issues then we can go from there,

Good luck!

What makes me think of the prog pin as the reason for the crash is that when the Teensy is connected to a pc and the Teensy loader is running then after the crash there is a code upload and then a reset. Whithout the Teensy loader beeing active, or when connected to e.g. the power bank (Li-Ion) the Teensy just hangs and does not reset. Isn't that an indication that the prog pin has been pulled low, as the reset is only happening after Code has ben uploaded, but not without code upload!?
Thanks for the help!
 
I'm not completely clued-up on the teensy programming logic. Obviously something is causing your teensy to go into bootloader mode. This can be done a number of ways;
Pressing program button
Toggling program pin
USB command
Teensy code command

But out of all the teensys in the world (1000s?, 10s of 1000s?) it's very unlikely that you have one that is randomly toggling it's own program button. Most likely I would say your motor is creating a spike in current draw on the 5v line. This current draw could be enough to briefly reset the power on the teensy. These power reset on the teensy (say for 10ms) could easily cause it to reset in a variety of ways that may match a "re-program" condition. That's why your seeing it reprogram randomly. Your method of pulling the program pin up to 3v3 may be enough to help the situation but it's unlikely to fix the route cause.
 
I'm not completely clued-up on the teensy programming logic. Obviously something is causing your teensy to go into bootloader mode. This can be done a number of ways;
Pressing program button
Toggling program pin
USB command
Teensy code command

But out of all the teensys in the world (1000s?, 10s of 1000s?) it's very unlikely that you have one that is randomly toggling it's own program button. Most likely I would say your motor is creating a spike in current draw on the 5v line. This current draw could be enough to briefly reset the power on the teensy. These power reset on the teensy (say for 10ms) could easily cause it to reset in a variety of ways that may match a "re-program" condition. That's why your seeing it reprogram randomly. Your method of pulling the program pin up to 3v3 may be enough to help the situation but it's unlikely to fix the route cause.

There is a thread (https://forum.pjrc.com/threads/29441-Teensy-LC-resets-due-to-EMI?highlight=reset+emi) where someone else had the same issue and Paul recommended to connect 3.3V to prog to see if it is a problem with the "layout" (10 kOhm pullup) or the chip itself!
 
My mistake. I wasn't aware of this issue. Okay then it's quite possibly the same issue. I guess testing with separate 5v supply would be worthwhile anyway. That post was from 2015 so maybe Paul has an update on the Teensy LC situation?
 
I’d never run a motor on USB power. It’s not meant for driving motors. use 2 separate powersupplies and common ground for better results
 
I now did tests with a Teensy Lc a Teensy 3.2 and an Arduino Micro and the drv8838 (connected to the motor) on a breadboard. Before doing the tests I updated the ARDUINO IDE from 1.8.5 to 1.8.7 and the Teensy loader from 1.40 to 1.44 (beta #2).
I wrote code that switches the motor on and off for four secs each. The result is the same with all three boards (Teensy Lc, Teensy 3.2 and Arduino Micro), the code does not crash anymore, but the usb connection to the pc sometimes is lost and then regained.
My question now is: Does the Teensy loader update the firmware of the boot-chip (or how to call it) of the Teensy, so that a new firmware is the reason for the different behavior now?

Even if not I might dare to resolder the drv8838 a new Teensy Lc and hope that the reset problems will not show up again (considering that the final power supply will be a usb-power bank capable of delivering 2A). If the old problem will reoccur I first will try a different motor with the same size and then if the problems still exists I would switch to a smaller motor (sol300). The sol300 motor should have enough power and I used that motor without any problems (but with different motor driver) in a previous Teensy-project (https://www.youtube.com/watch?v=9pMIs6gJhBM)!
 
For failing USB can you check return GND current over USB? IIRC I had cut VUSB<>VIN and saw that with externally powered 32x32 LED matrix. I was seeing over 1 Amp returning over the GND to the PC until I added more GND from matrix to the base PCB supplying the external power. That made USB reliable and dropped GND return to PC.

PJRC can it seems reprogram the external bootloader chip with a new version of TeensyLoader - but only recall seeing notes of it being done once for the T_3.5 and 3.6 after they were released.
 
For failing USB can you check return GND current over USB? IIRC I had cut VUSB<>VIN and saw that with externally powered 32x32 LED matrix. I was seeing over 1 Amp returning over the GND to the PC until I added more GND from matrix to the base PCB supplying the external power. That made USB reliable and dropped GND return to PC.

I still don't use a separate power supply for the motor! I don't see the need, as running a motor via usb successfully is only a matter of how much current the power supply is able to deliver and the 2A of my power bank should do in this case!
 
I still don't use a separate power supply for the motor! I don't see the need, as running a motor via usb successfully is only a matter of how much current the power supply is able to deliver and the 2A of my power bank should do in this case!

But you should, even only to see if this is the issue.
 
My question now is: Does the Teensy loader update the firmware of the boot-chip (or how to call it) of the Teensy, so that a new firmware is the reason for the different behavior now?

there are two programs on the teensy, the one in the bootloader chip, which only PJRC can change.
then there is the program in the main MCU, which is the one you are uploading. This user program CANNOT modify the program in the other chip.
 
After the more or less successful breadboard tests I connected the cables of the motor-driver drv8838 to a brand new Teensy LC. Now the Motor ran without any issues. I then connected the (Pololu) VL53L0X distance-sensor board (I didn't mention before that this was connected as I didn't think of it as the reason for the issue). After the start of this final assembly the issue with the code uploads and resets happened again. This was very confusing. I then cut the vcc cable from the sensor board and started again, but still the same issue. I then cut everything except the cable that was connected between the GND (beside pin 0) of the Teensy and GND of the sensor-board -> Still the same issue (when the motor is close to the board). Only when I cut this cable, the Teensy ran without problems (see attached picture). So it seems that the motor induces current on the GND plane of the VL53L0X-board (or what)!?
EMI issue.jpg
 
Seems like you found the source of the problem … adding this to your sketch it should print out the reason the MCU restarted.

Code:
void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 5000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

  int resetReasonHw;
  resetReasonHw = RCM_SRS0;
  resetReasonHw |= (RCM_SRS1 << 8);
  resetReason( resetReasonHw );

// …
}


void resetReason( int resetReasonHw ) {
  uint16_t mask = 1;
  //  Serial.print(strReason);
  Serial.print(">>> Reason for 'reset': ");
  Serial.print(resetReasonHw, HEX);
  do {
    switch (mask & resetReasonHw) {
      //RCM_SRS0
      case 0x0001: Serial.print(F(" wakeup")); break;
      case 0x0002: Serial.print(F(" LowVoltage"));  break;
      case 0x0004: Serial.print(F(" LossOfClock")); break;
      case 0x0008: Serial.print(F(" LossOfLock")); break;
      //case 0x0010 reserved
      case 0x0020: Serial.print(F(" wdog")); break;
      case 0x0040: Serial.print(F(" ExtResetPin")); break;
      case 0x0080: Serial.print(F(" PwrOn")); break;

      //RCM_SRS1
      case 0x0100: Serial.print(F(" JTAG")); break;
      case 0x0200: Serial.print(F(" CoreLockup")); break;
      case 0x0400: Serial.print(F(" SoftWare")); break;
      case 0x0800: Serial.print(F(" MDM_AP")); break;

      case 0x1000: Serial.print(F(" EZPT")); break;
      case 0x2000: Serial.print(F(" SACKERR")); break;
        //default:  break;
    }
  } while (mask <<= 1);
  Serial.println(" :: done Reason");
}
 
Sorry, I forgot to run the code, but tried to solve the issue by eliminating interference. Therefore i drilled the motor cables (a little), and added three 100nF capacitors. One across both motor terminals and one from each terminal to the motor's body. Additionally I added a 4k resistor between prog and 3.3V.
And voilà, no more problems (practically). I here and there (very rarely) encounter a reset (with programming) when the "gadget" is connected to the pc (and when the motor is running), but not when it is connected to the power bank.
Thanks to everybody who tried to help!
 
Status
Not open for further replies.
Back
Top