Using serial port A on a BL4s200, so close...

For clarification, when I talk about the 10-pin J1 header I�m talking about the target for the 10-pin PROG connector or the 10-pin DIAG connector.

It is documented that the BL4S200 won�t let me use the serial port A port as a redirect for the stdio window as per the instruction detailed in Samples/STDIO_SERIAL.C of the DC 10.56.That program wants me to redirect stdio window to serial E or serial F. Unfortunately, both of those ports are in use for my application.

In the other single computer board I�ve tested the BL2600, I was allowed to use the serial port A as per its stdio_serial.c program in the DC 9.62 samples directory. Using the following code:

#define STDIO_DEBUG_SERIAL SADR //for run mode and the Diag port!!!
#define STDIO_DEBUG_BAUD 115200

By accident, I left these lines in my code when I ported over my program to the BL4s200, and was pleasantly surprised that it did work, I was able to use the serial port A in run mode, but here�s the issue:

If I completely disconnect the Diag port connector so I don�t have a connection to serial port A, it looks like the transmission portion of serial E is not working. My timed TX message that goes out on serial E is not being received by its hyper-terminal session unless I plug the 10-pin DIAG connector back into the 10-pin J1 header. I don�t know if the receive portion of serial E is broken or not, and I know nothing of serial port F. It does appear that the rs485 port on Serial C TX is working and is not affected by serial port A

I realize this is not documented functionality of the Serial port A, and it is documented that I am not allowed to use the Serial port A on the BL4S200, but I think we are just a lib fix away from getting it to work (very similar to the previous issue we had with the serial ports interfering with each other.) I�m hoping that the engineers that were able to fix the dependency issues with the ports can do something here as well.

The point is, it seems serial port A does in fact work, and the only issue is that is can�t suspend if for whatever reason if it does not see a connection on the 10-pin J1 header. For that matter, if I had a flag that I could check to see if port A is either: 1) in debug mode, 2) in run mode but not connected or 3) in run mode but connected. I think that is an effective workaround.

Alternately, if someone can tell me what is required to simulate a connection on the 10-pin Diag connector I could work with that. I�ve tested the program with a hooked up cable to a pc with no software running to talk to serial port A, (aka, I don�t have a hyper-terminal session active ) and the I/O on serial port E seems to be ok. This leads me to believe that this is a simple hardware issue check for voltage on one of the pins of the 10-pin DIAG connector (RTS/CTS high???) so If I put some circuitry between the 10-pin J1 header and the 10-pin PROG/DIAG cable that supplied xxx voltage to pin yyy if there is none detected on the real 10-pin DIAG connector that would work. I hope I explained that ok.

My guess is that serial port A is using RTS, CTS in some fashion, and as a result this makes for higgly-piggly (that�s a technical term) when there is a disconnect. All I want is that TX fall to the floor (and any RX to go unanswered). If I could check a flag for RTS, CTS (or whatever is present if and only if there is connectivity on the 10-pin J1 header) I can use that to programmatically not use STDIO.