Sign in
Search rabbit-semi
Subscribe to rabbit-semi
Ads
Discussion Groups
See Also
Discussion Groups | Rabbit-Semi | Using serial port A on a BL4s200, so close...
This is a group for folks designing and programming embedded systems using the Rabbit Semiconductor C-programmable microcontroller. Rabbit Semi is a spin-off from Z-World who makes a variety of embedded modules and tools. This group is not affiliated with either Rabbit or Z-World, but is a user forum for sharing ideas, asking questions, flaunting knowledge, and other typical user group stuff. The Rabbit is a powerful uC, supported by a full-featured C-compiler.
Using serial port A on a BL4s200, so close... - Jon L - Nov 12 11:43:33 2009
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.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
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.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Using serial port A on a BL4s200, so close... - Tom Collins - Nov 14 15:15:40 2009
On Nov 12, 2009, at 8:40 AM, Jon L wrote:
> 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
Many times that's an indication of a grounding problem. The DIAG
connector is providing a ground between the PC and Rabbit.
Check your cabling for serial port E and make sure you have the
ground attached correctly.
If it is grounded, make sure you haven't configured port E to use
flow control with the CTS pin on the programming header. You'd have
to call serEflowcontrolOn() to enable it, and it's configured with
macros like SERE_CTS_PORT and SERE_CTS_PIN. Double check those macro
names -- I'm not at my PC to verify them.
-Tom
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> 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
Many times that's an indication of a grounding problem. The DIAG
connector is providing a ground between the PC and Rabbit.
Check your cabling for serial port E and make sure you have the
ground attached correctly.
If it is grounded, make sure you haven't configured port E to use
flow control with the CTS pin on the programming header. You'd have
to call serEflowcontrolOn() to enable it, and it's configured with
macros like SERE_CTS_PORT and SERE_CTS_PIN. Double check those macro
names -- I'm not at my PC to verify them.
-Tom
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Using serial port A on a BL4s200, so close... - Jon L - Nov 14 16:09:21 2009
--- In r...@yahoogroups.com, Tom Collins
>
> On Nov 12, 2009, at 8:40 AM, Jon L wrote:
> > 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
>
> Many times that's an indication of a grounding problem. The DIAG
> connector is providing a ground between the PC and Rabbit.
>
> Check your cabling for serial port E and make sure you have the
> ground attached correctly.
>
> If it is grounded, make sure you haven't configured port E to use
> flow control with the CTS pin on the programming header. You'd have
> to call serEflowcontrolOn() to enable it, and it's configured with
> macros like SERE_CTS_PORT and SERE_CTS_PIN. Double check those macro
> names -- I'm not at my PC to verify them.
>
> -Tom
>
Good call on the Grounding Issue! I only had RX and TX from the rabbit to a DB9 to a db9 to USB converter. As soon as I attached pin 5 of the db9 to a rabbit ground all is well. That was exactly what the issue was.
I was fooled because of two reasons:
1) The DIAG port connects to the PC on its own USB connection, I would of expected the other USB to be a floating ground regardless of the DIAG port arrangement.
2) The documentation in STDIO_SERIAL.C /DC 10.56 for the Rabbit 4000 processors expressly says you shouldn't use serial port A, so I jumped to the conclusion that that is where the problem laid.
Meantime, so why does STDIO_SERIAL.C /DC 10.56/ rabbit 4000 say you can't use serial port A? It seems to work fine for me...
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )