[ECOS] Assabet lock-up after 30 seconds

[Richard Panton <rpanton at 3glab dot com>]

We've just investigated a nasty problem with the Assabet board that I'm
quite surprised no-one has mentioned on this list before.

Problem:
    After 30 seconds of inactivity, the Assabet board appears to lock up,
failing to respond to interrupts. However, pressing the STOP button in GDB
appears to unlock the system.

Reason:
    The RS232 driver on Assabet has an auto-power-down mode. So, after 30
seconds of no GDB packets being transmitted, the RS232 drivers power down.
When the next packet is sent from Assabet, the first 6 characters are
corrupted because the RS232 drivers power up VERY slowly. This means that
the GDB front-end does NOT see a valid GDB packet, and so will not send an
acknowlegment (or a NAK). The code on the Assabet board sits in a loop in
the cyg_hal_diag_mangler_gdb_putc() routine, with interrupts disabled,
waiting for the ACK (or for a CTRLC, which explains why the STOP button
unlocks the system).

Does anyone have any good ideas for a solution? The only ideas I have
about this are not what I would call good:

* There's no way of forcing the RS232 drivers to stay on that we can see.

* Having a separate thread that printf()s something every 29 seconds will
work, but that requires a KERNEL and timers in the eCos build.

* Sending 6 NUL characters before each packet would work, but would
probably screw up the GDB protocol.

* Toggling the RS232 power (to power-off, then back to auto-power-off) MAY
work, provided there's a 6 character delay before transmitting the first
character of the GDB packet. Of EVERY GDB packet....

Best Regards
 -- 
Richard Panton              Systems Architect          3G Lab Ltd.
richard.panton@3glab.com    http://www.3glab.org/