2
\$\begingroup\$

I am observing strange behavior with my Leonardo board.

I use 9V AC/DC adapter to power it. Relay extension board is attached to digital pins, and relays are used to control several valves and motors.

I've left only one small 220V 0.2A AC motor for testing. It is connected to the same wall socket as 9V adapater. Arduino connects to the notebook with a short USB cord equipped with ferrite ring.

Now here is my problem: using the serial connection I turn relay on and off a few times and COM port connection dies sooner or later. PuTTY window displays error, the COM port stays listed in Windows Device manager, but I can't reestablish connection unless I plug USB cord out and back in. Surprisingly, Leonardo keeps running. I know for sure it doesn't reboot - I've added buzzer beep to the setup() to hear when it does.

It could be the noise caused by the motor's coils that messes with DC adapter - I don't have capacitors on them. (And it is not the relay board - it has diodes for every relay's coil). My question is different:

I wouldn't be so stunned if it was Arduino UNO. But Leonardo has a single chip for both USB communications and work - so if one fails, the second should, too - right?

How could it be happening?

\$\endgroup\$
7
  • \$\begingroup\$ It sounds to me as if the problem is your notebook and the USB-to-serial adapter, judging by your references to putty and a COM port. Can you put a 'scope on the TX line from the Arduino and tell us what you see? \$\endgroup\$
    – Joe Hass
    Jan 11, 2014 at 12:54
  • \$\begingroup\$ @JoeHass Arduino Leonardo has USB built into MCU (ATMega32u4). OP: maybe you could check the USB registers to see what is happening? \$\endgroup\$
    – geometrikal
    Jan 11, 2014 at 13:46
  • \$\begingroup\$ The presence of COM Port device under Windows Device Manager can be tricky sometimes, this also happens with FTDI sometimes i.e. device appears even after losing communication. The presence only indicates that device driver is still loaded in memory. So if you can't communicate to leonardo over COM that could mean an error on behalf of CDC driver communication( unlikely) or your leonardo might be struck somewhere( likely ). A Logic analyzer(or a USB Analyzer) can help you find out the actual problem. \$\endgroup\$
    – vyi
    Jan 11, 2014 at 16:59
  • 1
    \$\begingroup\$ I've sorted it out (kind of). Probably, the issue was somehow related either to the faulty DS1307 RTC clock module, and/or the amount of SRAM memory my sketch used. I've been experiencing issues with Leonardo not syncing its timer to RTC in 50% cases, dropped this functionality from my code, freed about 1Kb of SRAM - and it now works flawlessly. Probably, if I were using UNO, I'd have had reboots, but since Leonardo is different - it was "half-freezing". \$\endgroup\$
    – Alexander
    Jan 11, 2014 at 19:29
  • \$\begingroup\$ I had the same problem while trying to control a motor with a logic mosfet connected to digital pin3 and monitoring the speed data from serial monitor... I am almost sure that the problem is motor-mosfet noise... because the serial port is never lost if the motor is not running... It is lost some time after powering the motor (12v from a different supply, sharing ground)... but script continues to work.. only serial port is lost... \$\endgroup\$
    – user92831
    Nov 26, 2015 at 19:35

2 Answers 2

Reset to default
0
\$\begingroup\$

Although they are one the same chip, the USB and MCU circuits can function independently. For example, the USB part can be used to reset the MCU part.

\$\endgroup\$
0
\$\begingroup\$

I've sorted it out (kind of).

Probably, the issue was somehow related either to the faulty DS1307 RTC clock module, and/or the amount of SRAM memory my sketch used. I've been experiencing issues with Leonardo not syncing its timer to RTC in 50% cases, dropped this functionality from my code, freed about 1Kb of SRAM - and it now works flawlessly.

Probably, if I were using UNO, I'd have had reboots, but since Leonardo is different - it was "half-freezing".

\$\endgroup\$
1
  • \$\begingroup\$ Sure, it's fairly easy to crash an MCU's USB stack, so much so that USB tends not to be a workable for debug output in cases where the firmware is too severely broken. It's also entirely possible for electrical noise to convince a hub to shut down the port you are using. \$\endgroup\$
    – Chris Stratton
    Feb 11, 2014 at 22:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.