TeensyLC dies on serial

Status
Not open for further replies.
J

JasonH

Member
I have a a few Teensys that are in the field. (Indoor factory environment) that control things like lights. I open the serial device /dev/ttyACM0 and write out a struct to control these lights. Eventually the moduel stops responding:
Code: 
  File "/usr/lib/python3.8/asyncio/streams.py", line 358, in write
    self._transport.write(data)
  File "/home/work/env/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 120, in write
    n = self._serial.write(data)
  File "/home/work/env/lib/python3.8/site-packages/serial/serialposix.py", line 570, in write
    if e.errno not in (errno.EAGAIN, errno.EALREADY, errno.EWOULDBLOCK, errno.EINPROGRESS, errno.EINTR):
KeyboardInterrupt

Then some times, it disappears off the bus completely (and is not shown by `lsusb`):

Code: 
  File "/home/work/env/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 438, in open_serial_connection
    transport, _ = yield from create_serial_connection(
  File "/usr/lib/python3.8/asyncio/coroutines.py", line 124, in coro
    res = func(*args, **kw)
  File "/home/work/env/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 410, in create_serial_connection
    ser = serial.serial_for_url(*args, **kwargs)
  File "/home/work/env/lib/python3.8/site-packages/serial/__init__.py", line 88, in serial_for_url
    instance.open()
  File "/home/work/env/lib/python3.8/site-packages/serial/serialposix.py", line 268, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'


1. Has this been seen by other people elsewhere?
2. When writing my code, I observed that connecting resets the serial buffer. This of good.
3. Resetting the device (the button is not accessible so it is removed from the USB hub and replugged in) fixes the issue temporarily.
4. Is there a way to use the teensy_loader_cli to reset the device without code load?
5. Note: that I tried to use teensy_loader_cli, and it did not see the device though it was plugged in.

Edit:
6. Can we set some kind of self-reset interrupt?
 
Last edited by a moderator:
It seems that code is faulting in some fashion from memory problem - bad pointer or array overrun?

That can halt operation and may leave USB stack running and online for a reset - or it might trash the USB stack as well and take the USB offline. It seems this is what is being observed.

TyCommander is SerMon ( and upload ) tool of choice here - so not much understanding of teensy_loader_cli.

TyCommander gives GUI used for SerMon/Upload and it incorporates a RESET when it can talk to a Teensy that just restarts the device. It has a corresponding CLI version that I expect has the same features.

Looking at the OPEN TyCommander source on github may show if the RESET could be incorporated into the Python code it seems is in use? This may also be in the Teensy CLI? But when the Teensy USB fails to appear like in the second case above - it takes a full power off restart.

Either the Teensy is messing up memory and faulting, or perhaps somehow the interface code/machine is just losing track of the Teensy.
 
First thing would be going through the code looking at any use of pointers and arrays where they could be getting out of bounds usage. Or any dynamic memory allocation or usage?

To dynamically debug it would take having a repro case that was easy/expected to trigger. Then the GDB debugger might help if setup in the code, or even turning on the fault detection code in the Teensy CORE code that is disabled for release.

Though not sure the GDB code is setup to work on the T_LC? I saw it to be usable when it was posted - but that wasn't looking for T_LC function.

But going to any effort with that without having a way to make it happen wouldn't be productive, and it sounds like it can run some time - perhaps unattended before the problem occurs?

"control things like lights" sounds simple - or could be involved - but fitting in a T_LC without stressing the resources could be less involved code?

However given is is controlling "things like lights" depending on what those things are there could be some electrical influence affecting the T_LC if not shielded and properly isolated from such energies.
 
So a bit of a switcheroo happened to me. I thought I had this figured out, but they swapped the LC with 4.0 on the production boards, so we went from a little RAM to a LOT. I had computed the number of leds and the required memory to be over what was available, but now, my math says we have 400k free. S I'm back to the drawing board.


a
 
The only dynamic memory is in the NeoPixel constructor, which allocates the RGB/RGBW storage for the strand. Then it's just setting pixels, and reading some analog pins
 
Swapping LC for a T_4.0 is a big swap :)

Doesn't sound like there should be an issue then with memory - or memory abuse with not much going on dynamically.

The GDB debug thread would certainly apply. But no real idea of what this system looks like or how it interacts/interfaces with the world: PC and "setting pixels, and reading some analog pins"

If the GDB were tested and setup it would give source code info and fault notices - but if the USB port is on Python doing something ( as inferred from p#1 ) - not sure how it would be setup to work in parallel with that.
 
Status
Not open for further replies.
Back
Top