Hi Andy,
in one of your previous posts you suggested:
Have you implemented this function? It would save my day!
My problem is, that the "OS" (Windows XP) asserts RTS and DTR once FM closes the COM port. It also sends a break!
1.
Assertion of the handshake lines immediately resets the device, hence the program in RAM, which has just been started with the EXECUTE command, comes to a sudden death...
2.
Not using hardware handshaking to control DTR/RTS in FM is no option, because of the break being sent by Windows:
Assume you put the board into ISP mode manually, before you start FM. The LPC sees the break on its RXD0 line, and interprets this as the start bit of the "?" character used for auto-bauding! This results in the auto-bauding to calculate a wrong baud rate.
3.
The default COM port state (when no application is using it) seems to be related to a weird Plug&Play feature for serial ports. Not sure why this is still used, since serial mice are rather old-fashioned these days...
Anyway, I didn't find a way to disable it.
Since I need the program in RAM to run for a short time only, a configurable delay would be extremely helpful!
Rolf
in one of your previous posts you suggested:
Quote from: Andy Ayre on May 09, 2008, 10:35:59 AM
How about implementing a user configurable delay along with the Go operation? The delay is the length of time to wait after sending the command before the COM port is closed.
For example specifying 10 seconds will send the Go command and then wait 10 seconds before closing the COM port, which will stop execution from RAM.
Have you implemented this function? It would save my day!
My problem is, that the "OS" (Windows XP) asserts RTS and DTR once FM closes the COM port. It also sends a break!
1.
Assertion of the handshake lines immediately resets the device, hence the program in RAM, which has just been started with the EXECUTE command, comes to a sudden death...
2.
Not using hardware handshaking to control DTR/RTS in FM is no option, because of the break being sent by Windows:
Assume you put the board into ISP mode manually, before you start FM. The LPC sees the break on its RXD0 line, and interprets this as the start bit of the "?" character used for auto-bauding! This results in the auto-bauding to calculate a wrong baud rate.
3.
The default COM port state (when no application is using it) seems to be related to a weird Plug&Play feature for serial ports. Not sure why this is still used, since serial mice are rather old-fashioned these days...
Anyway, I didn't find a way to disable it.
Since I need the program in RAM to run for a short time only, a configurable delay would be extremely helpful!
Rolf