USB Comm Freezes

Created Thu, 09 Feb 2017 05:19:26 +0000 by PICSROCK

PICSROCK

Thu, 09 Feb 2017 05:19:26 +0000

I have incorporated the uc32 board into a very high end laser system. The program does basic digital read/writes on various pins, uses some interrupts, and reports a stream of info to a computer using the Serial.available(), Serial.read(), Serial.println() etc. At some point the USB comm causes erratic behavior; the USB port is no longer recognized by the computer, occasionally this also causes totally erratic behavior from the uc32 and the program is no longer functioning. This usually requires a restart/power cycle of the micro-controller to get things working again. I have been struggling with this problem for some time and REALLY need help. This circuit is now a major part of these systems and I may have to do a complete overhaul if I cannot solve the problem. The program is attached.

majenko

Thu, 09 Feb 2017 12:01:11 +0000

The USB communication is all managed by an FT232R chip. If the USB itself is failing and the port is disappearing on the computer then it sounds to me like the FT232R is failing in its duty to control the USB connection. Your program has nothing to do with that USB interface, it just throws UART data at it to be forwarded to the computer.

I would first focus on the power system for your project - make sure you're not experiencing any brown-outs that would cause the FT232R to drop the connection.

PICSROCK

Thu, 09 Feb 2017 20:34:15 +0000

Thanks for your reply. I have tried to hunt down power problems but have seen no sign of power issues so far. There are several other USB devices in the system that do not have any USB problems. What could be different about the microcontroller compared to these other devices?

majenko

Thu, 09 Feb 2017 20:58:48 +0000

Even if the MCU went up in smoke the USB connection shouldn't be affected (unless the going up in smoke caused a power problem).

PICSROCK

Fri, 10 Feb 2017 06:37:25 +0000

The port still shows up in the windows device manager, but communication is impossible. The uc32 does not respond. When I started this post, I used the words "micro-controller" to refer to the entire uc32 board. Now I see that is a poor choice of words as the problem seems to be associated with the FT232R chip and the micro-controller seems to be working fine.

majenko

Fri, 10 Feb 2017 10:21:15 +0000

Ok - so if the port remains then it may be the MCU that is dying and not the FT232R. You would need to connect something (external FT232 dongle, for example) to pins 0/1 to confirm if, when it does crash, the MCU is responding or not on the serial port.

If not then it may be something to do with your program that is causing it to lock up.

One thing I do notice in your program is you are using signed integers to work with time. That's wrong - you should be working with unsigned integers (uint32_t specifically, or one of its aliases, such as time_t or size_t depending on what you are doing at the time).

Your "ElapsedTime" calculation, for example, should really be:

uint32_t StartTime = micros();
...
if (micros() - StartTime >= TimeOut) { ... }
...

PICSROCK

Mon, 13 Feb 2017 04:10:14 +0000

Thanks for your advice. I have fixed the unsigned integer issue. I believe I recently found a solution to my problem but it does not make any sense to me. Inspired by your advice, I tried to check if the MC sees bytes coming in to the serial port when it crashes. I added a section to the MC program that reports the number of bytes at the serial port to another MC on the OTHER serial port (pins 38, 39) using serial1.write. Somehow adding 2 lines to the code (Serial1.begin(9600) in the setup and Serial1.write(BytesAtPort) in the main loop) caused the MC to stop crashing. I delete those lines, it crashes within minutes, add them back in and it doesn't crash ever (had it running for 2 days straight). Can you offer any insight into what could be going on here?

majenko

Mon, 13 Feb 2017 11:05:09 +0000

That is bizarre to say the least.

Is it only the printing that keeps it from crashing? I.e., does it crash if you have the Serial1.begin(9600) but not the Serial1.write?

rasmadrak

Mon, 13 Feb 2017 22:31:48 +0000

I had a similar issue a while back - I had a watchdog triggered by an interrupt routine, which also handled rendering. I did a quick test to see if the watchdog worked by putting in a divide by zero in the main loop. What happened was a bit puzzling; The main loop froze in place, but rendering of the display kept running and the watchdog kept the PIC alive. So I moved the watchdog "kick" to the main loop and it behaved correctly.

Don't know if it's relatable to this issue really, but when a uC stops working it's usually an unhandled error or timing issue.
If you haven't got a watchdog in place, try inserting one to see if it reboots?