Hi all.
This isn't actually related to lpc family but i did not find a solution
anywhere so i posted the query here. I am making a serial interface for
P89V51RD2 with max202 ic. I have previously made serial interfaces for lpc
series using max3232 without any problems. This is the problem i am facing:
When i checked the IC with a loopback test then it is returning garbage values.
I have shorted the TxD and RxD (pins 11 and 12) for the test. These pins i
intend to connect to the controller. When i open flash magic hyperterminal (i
use win7 so dont have the windows hyperterminal) and type something on the
keyboard, i get all garbage values on the o/p screen. The interesting thing is,
i dont get any o/p if the baudrate is below 38400. Above that i get only garbage
values.
Can anyone help me in this matter? Caps used are 0.1uF according to the
datasheet.
-Mayuresh
RS232 problem.
Started by ●September 7, 2010
Reply by ●September 7, 20102010-09-07
On Tue, 2010-09-07 at 16:55 +0000, MAYURESH M wrote:
> When i checked the IC with a loopback test then it is
> returning garbage values. I have shorted the TxD and
> RxD (pins 11 and 12) for the test. These pins i intend
> to connect to the controller. When i open flash magic
> hyperterminal (i use win7 so dont have the windows
> hyperterminal) and type something on the keyboard, i
> get all garbage values on the o/p screen. The interesting
> thing is, i dont get any o/p if the baudrate is below
> 38400. Above that i get only garbage values.
>
> Can anyone help me in this matter? Caps used are
> 0.1uF according to the datasheet.
Hi Mayuresh,
First thing I would try is to short pin 2 and 3 of the
male SUBD9 connector which is on the back of the PC.
I am assuming you are using a real serial port and
not an USB-serial converter.
About the baudrate not going below 38400, that might
be the software itself not setting up the UART in
the correct way.
If all else fails pop in a Linux CD and run minicom.
With a voltmeter you can check the inputs and outputs
of the max202 while applying a logic level to the TTL
side of the IC.
roelof
> When i checked the IC with a loopback test then it is
> returning garbage values. I have shorted the TxD and
> RxD (pins 11 and 12) for the test. These pins i intend
> to connect to the controller. When i open flash magic
> hyperterminal (i use win7 so dont have the windows
> hyperterminal) and type something on the keyboard, i
> get all garbage values on the o/p screen. The interesting
> thing is, i dont get any o/p if the baudrate is below
> 38400. Above that i get only garbage values.
>
> Can anyone help me in this matter? Caps used are
> 0.1uF according to the datasheet.
Hi Mayuresh,
First thing I would try is to short pin 2 and 3 of the
male SUBD9 connector which is on the back of the PC.
I am assuming you are using a real serial port and
not an USB-serial converter.
About the baudrate not going below 38400, that might
be the software itself not setting up the UART in
the correct way.
If all else fails pop in a Linux CD and run minicom.
With a voltmeter you can check the inputs and outputs
of the max202 while applying a logic level to the TTL
side of the IC.
roelof
Reply by ●September 7, 20102010-09-07
Hi roelof
> First thing I would try is to short pin 2 and 3 of the
> male SUBD9 connector which is on the back of the PC.
did that. its working fine.
> I am assuming you are using a real serial port and
> not an USB-serial converter.
yeah its a true serial port right from the motherboard.
> About the baudrate not going below 38400, that might
> be the software itself not setting up the UART in
> the correct way.
i too suspect that it must be a flash magic problem. perhaps their hyperterminal isn't setting the port up correctly. you only get option for controlling the baudrate in FM but no options for controlling parity, flow control or data bits. Isn't there any clone for the good old windows hyperterminal for windows7?
-mayuresh
> First thing I would try is to short pin 2 and 3 of the
> male SUBD9 connector which is on the back of the PC.
did that. its working fine.
> I am assuming you are using a real serial port and
> not an USB-serial converter.
yeah its a true serial port right from the motherboard.
> About the baudrate not going below 38400, that might
> be the software itself not setting up the UART in
> the correct way.
i too suspect that it must be a flash magic problem. perhaps their hyperterminal isn't setting the port up correctly. you only get option for controlling the baudrate in FM but no options for controlling parity, flow control or data bits. Isn't there any clone for the good old windows hyperterminal for windows7?
-mayuresh
Reply by ●September 7, 20102010-09-07
Hi Mayuresh,
there is no problem with flash magic terminal. I've used it several times
with no problem at all. I actually find it much better than windows
hyperterminal, you just cannot change the settings for bit number, parity
and stop bit but those are the default 8N1 with no flow control.
I'd rather tell you to check for problems in your baud rate setting in the
uController than in flash magic terminal.
Since you can't even receive what you send when you short the max202 pins
your problem is not on the PC side.
Check your code for possible misreading of the data register, overrun
errors, or some other bug.
I just took a quick look at the max202 datasheet and you shouldn't be
shorting pin 11 with 12. Those are the TTL side of the max202 and should be
connected to your uC rx and tx pins. Pin 12 (connected to rx in your uC) is
being pulled high or low depending on the value at pin 13 as so you will not
receive what you are sending thru the tx pin (connected to the max pin 11).
You should be shorting pin 14 with 13 to receive what you send. If you still
don't receive what you send then your code is the problem.
Unless you remove the max202 when you short the pins, then shorting the uC
tx with rx (11 and 12 in the max202 socket) would work properly and the
problem would be in your code for sure.
Regards,
Bernardo Marques.
there is no problem with flash magic terminal. I've used it several times
with no problem at all. I actually find it much better than windows
hyperterminal, you just cannot change the settings for bit number, parity
and stop bit but those are the default 8N1 with no flow control.
I'd rather tell you to check for problems in your baud rate setting in the
uController than in flash magic terminal.
Since you can't even receive what you send when you short the max202 pins
your problem is not on the PC side.
Check your code for possible misreading of the data register, overrun
errors, or some other bug.
I just took a quick look at the max202 datasheet and you shouldn't be
shorting pin 11 with 12. Those are the TTL side of the max202 and should be
connected to your uC rx and tx pins. Pin 12 (connected to rx in your uC) is
being pulled high or low depending on the value at pin 13 as so you will not
receive what you are sending thru the tx pin (connected to the max pin 11).
You should be shorting pin 14 with 13 to receive what you send. If you still
don't receive what you send then your code is the problem.
Unless you remove the max202 when you short the pins, then shorting the uC
tx with rx (11 and 12 in the max202 socket) would work properly and the
problem would be in your code for sure.
Regards,
Bernardo Marques.
Reply by ●September 7, 20102010-09-07
> > be the software itself not setting up the UART
in
> > the correct way.
>
> i too suspect that it must be a flash magic problem. perhaps their
> hyperterminal isn't setting the port up correctly. you only get option for
> controlling the baudrate in FM but no options for controlling parity, flow
> control or data bits. Isn't there any clone for the good old windows
> hyperterminal for windows7?
>
You can try RealTerm - it's working fine for me under Windows Vista 32-bit
and Windows 7 64-bit. See
http://realterm.sourceforge.net/
Cheers
--
Olivier Gautherot
o...@gautherot.net
> > the correct way.
>
> i too suspect that it must be a flash magic problem. perhaps their
> hyperterminal isn't setting the port up correctly. you only get option for
> controlling the baudrate in FM but no options for controlling parity, flow
> control or data bits. Isn't there any clone for the good old windows
> hyperterminal for windows7?
>
You can try RealTerm - it's working fine for me under Windows Vista 32-bit
and Windows 7 64-bit. See
http://realterm.sourceforge.net/
Cheers
--
Olivier Gautherot
o...@gautherot.net
Reply by ●September 7, 20102010-09-07
Hi Bernardo,
I havn't connected the max202 circuit to the uC. Its on a different PCB. So there is no question of the uC code.
Secondly, i used to test max232 and max3232 in the same way, by shorting the pins 11 and 12 and they used to echo back on the terminal whatever i typed on the keyboard. Is there any other way to confirm the max202 IC is working?
Today if it doesn't work, i am going to replace the max202 with TI make max232.
-mayuresh.
--- In l..., Bernardo wrote:
>
> Hi Mayuresh,
>
> there is no problem with flash magic terminal. I've used it several times
> with no problem at all. I actually find it much better than windows
> hyperterminal, you just cannot change the settings for bit number, parity
> and stop bit but those are the default 8N1 with no flow control.
> I'd rather tell you to check for problems in your baud rate setting in the
> uController than in flash magic terminal.
> Since you can't even receive what you send when you short the max202 pins
> your problem is not on the PC side.
> Check your code for possible misreading of the data register, overrun
> errors, or some other bug.
>
> I just took a quick look at the max202 datasheet and you shouldn't be
> shorting pin 11 with 12. Those are the TTL side of the max202 and should be
> connected to your uC rx and tx pins. Pin 12 (connected to rx in your uC) is
> being pulled high or low depending on the value at pin 13 as so you will not
> receive what you are sending thru the tx pin (connected to the max pin 11).
> You should be shorting pin 14 with 13 to receive what you send. If you still
> don't receive what you send then your code is the problem.
>
> Unless you remove the max202 when you short the pins, then shorting the uC
> tx with rx (11 and 12 in the max202 socket) would work properly and the
> problem would be in your code for sure.
>
> Regards,
> Bernardo Marques.
>
I havn't connected the max202 circuit to the uC. Its on a different PCB. So there is no question of the uC code.
Secondly, i used to test max232 and max3232 in the same way, by shorting the pins 11 and 12 and they used to echo back on the terminal whatever i typed on the keyboard. Is there any other way to confirm the max202 IC is working?
Today if it doesn't work, i am going to replace the max202 with TI make max232.
-mayuresh.
--- In l..., Bernardo wrote:
>
> Hi Mayuresh,
>
> there is no problem with flash magic terminal. I've used it several times
> with no problem at all. I actually find it much better than windows
> hyperterminal, you just cannot change the settings for bit number, parity
> and stop bit but those are the default 8N1 with no flow control.
> I'd rather tell you to check for problems in your baud rate setting in the
> uController than in flash magic terminal.
> Since you can't even receive what you send when you short the max202 pins
> your problem is not on the PC side.
> Check your code for possible misreading of the data register, overrun
> errors, or some other bug.
>
> I just took a quick look at the max202 datasheet and you shouldn't be
> shorting pin 11 with 12. Those are the TTL side of the max202 and should be
> connected to your uC rx and tx pins. Pin 12 (connected to rx in your uC) is
> being pulled high or low depending on the value at pin 13 as so you will not
> receive what you are sending thru the tx pin (connected to the max pin 11).
> You should be shorting pin 14 with 13 to receive what you send. If you still
> don't receive what you send then your code is the problem.
>
> Unless you remove the max202 when you short the pins, then shorting the uC
> tx with rx (11 and 12 in the max202 socket) would work properly and the
> problem would be in your code for sure.
>
> Regards,
> Bernardo Marques.
>
Reply by ●September 7, 20102010-09-07
mayuresh:
i believe that bernardo may have misunderstood what you were trying to test.
he seems to be under the impression that you were trying to test your uC
code by using an "external loopback" at pins 13 & 14 (the "rs-232
side"). however, what i am hearing is that you are simply trying to
test your MAX202 chip by connecting it to your PC via an RS-232 cable
and applying an "internal loopback" on the "TTL (actually CMOS) side" of
the chip at pins 11 & 12, so that anything you type on the PC will go
out the cable to the MAX202, loopback, and go back to the PC and be
"echoed". if that is a correct understanding of what you have intended,
then your use of pins 11 & 12 is correct, just as it would be with the
MAX232/MAX3232.
frankly, if you are experiencing a problem with this setup, the only
thing i could suggest is to check the voltage supply and make sure that
your charge-pump caps are installed correctly (and are the recommended
type and value). note especially that this is a +5V supply part, so if
you are trying to power it using a 3.3v supply on the "micro" end, you
are going to have trouble (i know that several of the maxim "5v" parts
actually run at 3.3v at low data rates, but you can't count on this
working -- if you are using a 3.3v supply, you should pick one of the
maxim parts specified for 2.7v-3.3v systems.
by the way, i don't use flash magic terminal -- which is not to say that
there is anything wrong with it -- but i can tell you from (long)
experience that windows hyperterminal should NEVER be used for any uC
project, especially for debugging, because it is notorious for failing
to work at random times. i've used teraterm for years with no problem.
give it a try if your hardware checks out ok.
also, you might want to perform a "static" test on both ends of your
MAX202 by disconnecting it from both the PC and uC and then 1) short 13
& 14 and seeing what comes out pin 12 when pin 11 is left unconnected
(it has an internal pull-up), then ground pin 12 and verify that pin 11
toggles, then 2) short pin 11 & 12 and apply each input level (+/-) to
pin 13 and measure the corresponding levels at pin 14 to ensure it
toggles too. if your chip works in this "DC" test but fails once you
hook it up to changing levels, i'd be suspicious of the charge-pump
connections/components (i.e., it isn't properly generating the intended
+/- 10v levels to drive the RS-232 side of the chip when the voltage
levels are required to change rapidly) or that your PC interface isn't
using true RS-232 levels to begin with (check it on a scope to be sure
the levels look OK).
--
Gary Cordelli
Embedded Computer Engineer
Mentor Computer Consulting LLC
the embedded computer company
On 9/7/2010 9:34 PM, MAYURESH M wrote:
>
> Hi Bernardo,
>
> I havn't connected the max202 circuit to the uC. Its on a different
> PCB. So there is no question of the uC code.
>
> Secondly, i used to test max232 and max3232 in the same way, by
> shorting the pins 11 and 12 and they used to echo back on the terminal
> whatever i typed on the keyboard. Is there any other way to confirm
> the max202 IC is working?
>
> Today if it doesn't work, i am going to replace the max202 with TI
> make max232.
>
> -mayuresh.
>
> --- In l... ,
> Bernardo wrote:
> >
> > Hi Mayuresh,
> >
> > there is no problem with flash magic terminal. I've used it several
> times
> > with no problem at all. I actually find it much better than windows
> > hyperterminal, you just cannot change the settings for bit number,
> parity
> > and stop bit but those are the default 8N1 with no flow control.
> > I'd rather tell you to check for problems in your baud rate setting
> in the
> > uController than in flash magic terminal.
> > Since you can't even receive what you send when you short the max202
> pins
> > your problem is not on the PC side.
> > Check your code for possible misreading of the data register, overrun
> > errors, or some other bug.
> >
> > I just took a quick look at the max202 datasheet and you shouldn't be
> > shorting pin 11 with 12. Those are the TTL side of the max202 and
> should be
> > connected to your uC rx and tx pins. Pin 12 (connected to rx in your
> uC) is
> > being pulled high or low depending on the value at pin 13 as so you
> will not
> > receive what you are sending thru the tx pin (connected to the max
> pin 11).
> > You should be shorting pin 14 with 13 to receive what you send. If
> you still
> > don't receive what you send then your code is the problem.
> >
> > Unless you remove the max202 when you short the pins, then shorting
> the uC
> > tx with rx (11 and 12 in the max202 socket) would work properly and the
> > problem would be in your code for sure.
> >
> > Regards,
> > Bernardo Marques.
> >
i believe that bernardo may have misunderstood what you were trying to test.
he seems to be under the impression that you were trying to test your uC
code by using an "external loopback" at pins 13 & 14 (the "rs-232
side"). however, what i am hearing is that you are simply trying to
test your MAX202 chip by connecting it to your PC via an RS-232 cable
and applying an "internal loopback" on the "TTL (actually CMOS) side" of
the chip at pins 11 & 12, so that anything you type on the PC will go
out the cable to the MAX202, loopback, and go back to the PC and be
"echoed". if that is a correct understanding of what you have intended,
then your use of pins 11 & 12 is correct, just as it would be with the
MAX232/MAX3232.
frankly, if you are experiencing a problem with this setup, the only
thing i could suggest is to check the voltage supply and make sure that
your charge-pump caps are installed correctly (and are the recommended
type and value). note especially that this is a +5V supply part, so if
you are trying to power it using a 3.3v supply on the "micro" end, you
are going to have trouble (i know that several of the maxim "5v" parts
actually run at 3.3v at low data rates, but you can't count on this
working -- if you are using a 3.3v supply, you should pick one of the
maxim parts specified for 2.7v-3.3v systems.
by the way, i don't use flash magic terminal -- which is not to say that
there is anything wrong with it -- but i can tell you from (long)
experience that windows hyperterminal should NEVER be used for any uC
project, especially for debugging, because it is notorious for failing
to work at random times. i've used teraterm for years with no problem.
give it a try if your hardware checks out ok.
also, you might want to perform a "static" test on both ends of your
MAX202 by disconnecting it from both the PC and uC and then 1) short 13
& 14 and seeing what comes out pin 12 when pin 11 is left unconnected
(it has an internal pull-up), then ground pin 12 and verify that pin 11
toggles, then 2) short pin 11 & 12 and apply each input level (+/-) to
pin 13 and measure the corresponding levels at pin 14 to ensure it
toggles too. if your chip works in this "DC" test but fails once you
hook it up to changing levels, i'd be suspicious of the charge-pump
connections/components (i.e., it isn't properly generating the intended
+/- 10v levels to drive the RS-232 side of the chip when the voltage
levels are required to change rapidly) or that your PC interface isn't
using true RS-232 levels to begin with (check it on a scope to be sure
the levels look OK).
--
Gary Cordelli
Embedded Computer Engineer
Mentor Computer Consulting LLC
the embedded computer company
On 9/7/2010 9:34 PM, MAYURESH M wrote:
>
> Hi Bernardo,
>
> I havn't connected the max202 circuit to the uC. Its on a different
> PCB. So there is no question of the uC code.
>
> Secondly, i used to test max232 and max3232 in the same way, by
> shorting the pins 11 and 12 and they used to echo back on the terminal
> whatever i typed on the keyboard. Is there any other way to confirm
> the max202 IC is working?
>
> Today if it doesn't work, i am going to replace the max202 with TI
> make max232.
>
> -mayuresh.
>
> --- In l... ,
> Bernardo wrote:
> >
> > Hi Mayuresh,
> >
> > there is no problem with flash magic terminal. I've used it several
> times
> > with no problem at all. I actually find it much better than windows
> > hyperterminal, you just cannot change the settings for bit number,
> parity
> > and stop bit but those are the default 8N1 with no flow control.
> > I'd rather tell you to check for problems in your baud rate setting
> in the
> > uController than in flash magic terminal.
> > Since you can't even receive what you send when you short the max202
> pins
> > your problem is not on the PC side.
> > Check your code for possible misreading of the data register, overrun
> > errors, or some other bug.
> >
> > I just took a quick look at the max202 datasheet and you shouldn't be
> > shorting pin 11 with 12. Those are the TTL side of the max202 and
> should be
> > connected to your uC rx and tx pins. Pin 12 (connected to rx in your
> uC) is
> > being pulled high or low depending on the value at pin 13 as so you
> will not
> > receive what you are sending thru the tx pin (connected to the max
> pin 11).
> > You should be shorting pin 14 with 13 to receive what you send. If
> you still
> > don't receive what you send then your code is the problem.
> >
> > Unless you remove the max202 when you short the pins, then shorting
> the uC
> > tx with rx (11 and 12 in the max202 socket) would work properly and the
> > problem would be in your code for sure.
> >
> > Regards,
> > Bernardo Marques.
> >
Reply by ●September 7, 20102010-09-07
If you're still looking for a suitable Hyperterminal substitute, try out
Bray's Terminal. At http://hw-server.com/software/termv19b.html
I've been using it for over 5 years, and it's pretty good for what I need.
Lots of features like macros, etc.
:-)
Ahmad
On Wed, Sep 8, 2010 at 7:44 AM, Gary Cordelli wrote:
> mayuresh:
>
> i believe that bernardo may have misunderstood what you were trying to
> test.
>
> he seems to be under the impression that you were trying to test your uC
> code by using an "external loopback" at pins 13 & 14 (the "rs-232 side").
> however, what i am hearing is that you are simply trying to test your MAX202
> chip by connecting it to your PC via an RS-232 cable and applying an
> "internal loopback" on the "TTL (actually CMOS) side" of the chip at pins 11
> & 12, so that anything you type on the PC will go out the cable to the
> MAX202, loopback, and go back to the PC and be "echoed". if that is a
> correct understanding of what you have intended, then your use of pins 11 &
> 12 is correct, just as it would be with the MAX232/MAX3232.
>
> frankly, if you are experiencing a problem with this setup, the only thing
> i could suggest is to check the voltage supply and make sure that your
> charge-pump caps are installed correctly (and are the recommended type and
> value). note especially that this is a +5V supply part, so if you are
> trying to power it using a 3.3v supply on the "micro" end, you are going to
> have trouble (i know that several of the maxim "5v" parts actually run at
> 3.3v at low data rates, but you can't count on this working -- if you are
> using a 3.3v supply, you should pick one of the maxim parts specified for
> 2.7v-3.3v systems.
>
> by the way, i don't use flash magic terminal -- which is not to say that
> there is anything wrong with it -- but i can tell you from (long) experience
> that windows hyperterminal should NEVER be used for any uC project,
> especially for debugging, because it is notorious for failing to work at
> random times. i've used teraterm for years with no problem. give it a try
> if your hardware checks out ok.
>
> also, you might want to perform a "static" test on both ends of your MAX202
> by disconnecting it from both the PC and uC and then 1) short 13 & 14 and
> seeing what comes out pin 12 when pin 11 is left unconnected (it has an
> internal pull-up), then ground pin 12 and verify that pin 11 toggles, then
> 2) short pin 11 & 12 and apply each input level (+/-) to pin 13 and measure
> the corresponding levels at pin 14 to ensure it toggles too. if your chip
> works in this "DC" test but fails once you hook it up to changing levels,
> i'd be suspicious of the charge-pump connections/components (i.e., it isn't
> properly generating the intended +/- 10v levels to drive the RS-232 side of
> the chip when the voltage levels are required to change rapidly) or that
> your PC interface isn't using true RS-232 levels to begin with (check it on
> a scope to be sure the levels look OK).
>
> --
> Gary Cordelli
> Embedded Computer Engineer
> Mentor Computer Consulting LLC
> the embedded computer company
> On 9/7/2010 9:34 PM, MAYURESH M wrote:
>
> Hi Bernardo,
>
> I havn't connected the max202 circuit to the uC. Its on a different PCB. So
> there is no question of the uC code.
>
> Secondly, i used to test max232 and max3232 in the same way, by shorting
> the pins 11 and 12 and they used to echo back on the terminal whatever i
> typed on the keyboard. Is there any other way to confirm the max202 IC is
> working?
>
> Today if it doesn't work, i am going to replace the max202 with TI make
> max232.
>
> -mayuresh.
>
> --- In l... , Bernardo
> wrote:
> >
> > Hi Mayuresh,
> >
> > there is no problem with flash magic terminal. I've used it several times
> > with no problem at all. I actually find it much better than windows
> > hyperterminal, you just cannot change the settings for bit number, parity
> > and stop bit but those are the default 8N1 with no flow control.
> > I'd rather tell you to check for problems in your baud rate setting in
> the
> > uController than in flash magic terminal.
> > Since you can't even receive what you send when you short the max202 pins
> > your problem is not on the PC side.
> > Check your code for possible misreading of the data register, overrun
> > errors, or some other bug.
> >
> > I just took a quick look at the max202 datasheet and you shouldn't be
> > shorting pin 11 with 12. Those are the TTL side of the max202 and should
> be
> > connected to your uC rx and tx pins. Pin 12 (connected to rx in your uC)
> is
> > being pulled high or low depending on the value at pin 13 as so you will
> not
> > receive what you are sending thru the tx pin (connected to the max pin
> 11).
> > You should be shorting pin 14 with 13 to receive what you send. If you
> still
> > don't receive what you send then your code is the problem.
> >
> > Unless you remove the max202 when you short the pins, then shorting the
> uC
> > tx with rx (11 and 12 in the max202 socket) would work properly and the
> > problem would be in your code for sure.
> >
> > Regards,
> > Bernardo Marques.
> >
>
>
Bray's Terminal. At http://hw-server.com/software/termv19b.html
I've been using it for over 5 years, and it's pretty good for what I need.
Lots of features like macros, etc.
:-)
Ahmad
On Wed, Sep 8, 2010 at 7:44 AM, Gary Cordelli wrote:
> mayuresh:
>
> i believe that bernardo may have misunderstood what you were trying to
> test.
>
> he seems to be under the impression that you were trying to test your uC
> code by using an "external loopback" at pins 13 & 14 (the "rs-232 side").
> however, what i am hearing is that you are simply trying to test your MAX202
> chip by connecting it to your PC via an RS-232 cable and applying an
> "internal loopback" on the "TTL (actually CMOS) side" of the chip at pins 11
> & 12, so that anything you type on the PC will go out the cable to the
> MAX202, loopback, and go back to the PC and be "echoed". if that is a
> correct understanding of what you have intended, then your use of pins 11 &
> 12 is correct, just as it would be with the MAX232/MAX3232.
>
> frankly, if you are experiencing a problem with this setup, the only thing
> i could suggest is to check the voltage supply and make sure that your
> charge-pump caps are installed correctly (and are the recommended type and
> value). note especially that this is a +5V supply part, so if you are
> trying to power it using a 3.3v supply on the "micro" end, you are going to
> have trouble (i know that several of the maxim "5v" parts actually run at
> 3.3v at low data rates, but you can't count on this working -- if you are
> using a 3.3v supply, you should pick one of the maxim parts specified for
> 2.7v-3.3v systems.
>
> by the way, i don't use flash magic terminal -- which is not to say that
> there is anything wrong with it -- but i can tell you from (long) experience
> that windows hyperterminal should NEVER be used for any uC project,
> especially for debugging, because it is notorious for failing to work at
> random times. i've used teraterm for years with no problem. give it a try
> if your hardware checks out ok.
>
> also, you might want to perform a "static" test on both ends of your MAX202
> by disconnecting it from both the PC and uC and then 1) short 13 & 14 and
> seeing what comes out pin 12 when pin 11 is left unconnected (it has an
> internal pull-up), then ground pin 12 and verify that pin 11 toggles, then
> 2) short pin 11 & 12 and apply each input level (+/-) to pin 13 and measure
> the corresponding levels at pin 14 to ensure it toggles too. if your chip
> works in this "DC" test but fails once you hook it up to changing levels,
> i'd be suspicious of the charge-pump connections/components (i.e., it isn't
> properly generating the intended +/- 10v levels to drive the RS-232 side of
> the chip when the voltage levels are required to change rapidly) or that
> your PC interface isn't using true RS-232 levels to begin with (check it on
> a scope to be sure the levels look OK).
>
> --
> Gary Cordelli
> Embedded Computer Engineer
> Mentor Computer Consulting LLC
> the embedded computer company
> On 9/7/2010 9:34 PM, MAYURESH M wrote:
>
> Hi Bernardo,
>
> I havn't connected the max202 circuit to the uC. Its on a different PCB. So
> there is no question of the uC code.
>
> Secondly, i used to test max232 and max3232 in the same way, by shorting
> the pins 11 and 12 and they used to echo back on the terminal whatever i
> typed on the keyboard. Is there any other way to confirm the max202 IC is
> working?
>
> Today if it doesn't work, i am going to replace the max202 with TI make
> max232.
>
> -mayuresh.
>
> --- In l... , Bernardo
> wrote:
> >
> > Hi Mayuresh,
> >
> > there is no problem with flash magic terminal. I've used it several times
> > with no problem at all. I actually find it much better than windows
> > hyperterminal, you just cannot change the settings for bit number, parity
> > and stop bit but those are the default 8N1 with no flow control.
> > I'd rather tell you to check for problems in your baud rate setting in
> the
> > uController than in flash magic terminal.
> > Since you can't even receive what you send when you short the max202 pins
> > your problem is not on the PC side.
> > Check your code for possible misreading of the data register, overrun
> > errors, or some other bug.
> >
> > I just took a quick look at the max202 datasheet and you shouldn't be
> > shorting pin 11 with 12. Those are the TTL side of the max202 and should
> be
> > connected to your uC rx and tx pins. Pin 12 (connected to rx in your uC)
> is
> > being pulled high or low depending on the value at pin 13 as so you will
> not
> > receive what you are sending thru the tx pin (connected to the max pin
> 11).
> > You should be shorting pin 14 with 13 to receive what you send. If you
> still
> > don't receive what you send then your code is the problem.
> >
> > Unless you remove the max202 when you short the pins, then shorting the
> uC
> > tx with rx (11 and 12 in the max202 socket) would work properly and the
> > problem would be in your code for sure.
> >
> > Regards,
> > Bernardo Marques.
> >
>
>
Reply by ●September 8, 20102010-09-08
Hi Gary,
Thanks for suggesting teraterm. Its a very good software indeed.
Coming back to my problem, i tried everything but nothing worked. So eventually i swapped max202 with TI make max232. Now its working fine. Loopback test on rs232 and TTL sides give the correct results now.
Now i am encountering another problem. I am not able to enter the bootloader of P89V51RD2. I read on the internet that one of the easiest ways to enter the bootloader is to:
1. Open a terminal and keep the reset button of the uC pressed.
2. Keep the u button on the keyboard pressed to input a continuous string of capital 'U' while still keeping the reset button pressed.
3. Release the reset button and you should see the capital 'U's echoed back on the terminal.
If that happens then you have successfully entered the bootloader. But i am not getting any Us echoed back. My connections are correct...TXD of MAX232 to RXD of uC and RXD of Max232 to TXD of uC. Voltage levels are also correct. Don't know where i am going wrong.
-mayuresh
Thanks for suggesting teraterm. Its a very good software indeed.
Coming back to my problem, i tried everything but nothing worked. So eventually i swapped max202 with TI make max232. Now its working fine. Loopback test on rs232 and TTL sides give the correct results now.
Now i am encountering another problem. I am not able to enter the bootloader of P89V51RD2. I read on the internet that one of the easiest ways to enter the bootloader is to:
1. Open a terminal and keep the reset button of the uC pressed.
2. Keep the u button on the keyboard pressed to input a continuous string of capital 'U' while still keeping the reset button pressed.
3. Release the reset button and you should see the capital 'U's echoed back on the terminal.
If that happens then you have successfully entered the bootloader. But i am not getting any Us echoed back. My connections are correct...TXD of MAX232 to RXD of uC and RXD of Max232 to TXD of uC. Voltage levels are also correct. Don't know where i am going wrong.
-mayuresh
Reply by ●September 8, 20102010-09-08
On Wed, 2010-09-08 at 06:46 +0000, MAYURESH M wrote:
> If that happens then you have successfully entered the bootloader. But i am not getting any Us echoed back. My connections are correct...TXD of MAX232 to RXD of uC and RXD of Max232 to TXD of uC. Voltage levels are also correct. Don't know where i am going wrong.
Did you try this (from the datasheet page 18) :
The bootloader can also be executed by forcing the device
into ISP mode during a power-on sequence. This has the same
effect as having a non-zero status byte. This allows an
application to be built that will normally execute user
code but can be manually forced into ISP operation. This
occurs by holding PSEN LOW at the falling edge of reset.
roelof
> If that happens then you have successfully entered the bootloader. But i am not getting any Us echoed back. My connections are correct...TXD of MAX232 to RXD of uC and RXD of Max232 to TXD of uC. Voltage levels are also correct. Don't know where i am going wrong.
Did you try this (from the datasheet page 18) :
The bootloader can also be executed by forcing the device
into ISP mode during a power-on sequence. This has the same
effect as having a non-zero status byte. This allows an
application to be built that will normally execute user
code but can be manually forced into ISP operation. This
occurs by holding PSEN LOW at the falling edge of reset.
roelof
