Hello there! I've been working on my new AT91SAM7S-EK and the USART0.
I'm following the AT91SAM7S256 Serial Communications tutorial from James P.
Lynch and i've had some problems to make it work. To connect my board with
the computer and send/receive data, i used an USB/serial cable (pl2303) and the
program "realterm". To see where was the problem i ran the next tests:
1.- Channel mode normal. I activated the TXEMPTY interrupt to send data
infinitely to my computer. Result: nothing was received in the realterm program
(not even garbage). I know the TXEMPTY interrupt was met because before it sends
something with US_THR inside this interrupt, it makes the LED_D (or LED4
whathever you name it) "on" for a second and then off for another second and
then sends the one-byte data. So, the target started sending a byte each two
seconds to my computer, but as i say, the realterm got nothing.
2.- Channel mode normal. I activated the RXRDY interrupt to receive data. To
know if this interrupt is met, i set the program to turn on the LED_C when the
target received data. Result: The interrupt was never met, so mu board never got
the data i sent by the realterm.
3.- Channel mode local loopback. I left RXRDY and TXEMPTY interrupt activated,
each one with a 1 second blink with delay (RXRDY with LED_C and TXEMPTY with
LED_D) so to know if the interrupts where met. Result: The USART0 worked nice!
The two interrupts where met. LED_C and LED_D where blinking intermittently;
this meant that at least, internally, the at91sam7s256's USART0 was working
without problems. I even tested if if it was receiving the correct characters
that was sending, and that test worked too.
4.- Channel mode remote loopback. Configured like this, i understand that if i
send data, it goes from my computer to the DB9 port, then the st3232 chip, then
enters to the pin of the at91sam7s256 (RXD0) and internally this pin is
connected to the TXD0, so the same data gets back by this pin to the st2323
chip, then the db9 port and finally the computer. Result: The realterm sent data
but never got it back.
So im getting to the conclusion that although the usart0 port works (inside the
at91sam7s256), it seems that there is a hardware problem with the circuit from
the pins of the microcontroller to the DB9 port. NOW, my question is, do
i'm missing something? or it is definitely a hardware problem and the board
has to be changed.
I have reviewed the schematics, the configuration in the program, and everything
seems to be fine, and even works, like it showed the 3rd test. So i doubt is a
software error.
One detail i saw is that in the tutorial from p Lynch, he shows the multiplexing
table where it says that the RXD0 and TXD0 are in PA0 and PA1, BUT in the
at91sam7s256 datasheet and at91sam7s-ek user guide i downloaded, it shows that
the RXD0 and TXD0 are actually in PA5 and PA6. So i tested with the two
configurations and none of them worked. Fearing that maybe the usart was in
other pins (and not knowing what else could be wrong), i disabled all 32 PIOs
and set the peripheral A for the 32 lines. I ran the 4th test, and again the
computer received nothing.
By the way, all jumpers were closed.
So, any idea what could be wrong?, do i have to change my board?
Thanks to all!
USART0 AT91SAM7S-EK
Started by ●December 5, 2010
Reply by ●December 5, 20102010-12-05
Are you able to check the output to the PC with an oscilloscope - perhaps
the data rate isn't correct (if it's much too fast or slow then the PC may
not report even garbage). And what have you dont with the PC flow control -
if DSR isn't avtive then the PC will probably ignore all input. Try looping
back DTR/DSR and RTS/CTS (pins 4,6 and 7,8).
Cheers,
Frog
_____
From: A... [mailto:A...] On Behalf Of
d...@gmail.com
Sent: Monday, 6 December 2010 11:46 a.m.
To: A...
Subject: [AT91SAM] USART0 AT91SAM7S-EK
Hello there! I've been working on my new AT91SAM7S-EK and the USART0. I'm
following the AT91SAM7S256 Serial Communications tutorial from James P.
Lynch and i've had some problems to make it work. To connect my board with
the computer and send/receive data, i used an USB/serial cable (pl2303) and
the program "realterm". To see where was the problem i ran the next tests:
1.- Channel mode normal. I activated the TXEMPTY interrupt to send data
infinitely to my computer. Result: nothing was received in the realterm
program (not even garbage). I know the TXEMPTY interrupt was met because
before it sends something with US_THR inside this interrupt, it makes the
LED_D (or LED4 whathever you name it) "on" for a second and then off for
another second and then sends the one-byte data. So, the target started
sending a byte each two seconds to my computer, but as i say, the realterm
got nothing.
2.- Channel mode normal. I activated the RXRDY interrupt to receive data. To
know if this interrupt is met, i set the program to turn on the LED_C when
the target received data. Result: The interrupt was never met, so mu board
never got the data i sent by the realterm.
3.- Channel mode local loopback. I left RXRDY and TXEMPTY interrupt
activated, each one with a 1 second blink with delay (RXRDY with LED_C and
TXEMPTY with LED_D) so to know if the interrupts where met. Result: The
USART0 worked nice! The two interrupts where met. LED_C and LED_D where
blinking intermittently; this meant that at least, internally, the
at91sam7s256's USART0 was working without problems. I even tested if if it
was receiving the correct characters that was sending, and that test worked
too.
4.- Channel mode remote loopback. Configured like this, i understand that if
i send data, it goes from my computer to the DB9 port, then the st3232 chip,
then enters to the pin of the at91sam7s256 (RXD0) and internally this pin is
connected to the TXD0, so the same data gets back by this pin to the st2323
chip, then the db9 port and finally the computer. Result: The realterm sent
data but never got it back.
So im getting to the conclusion that although the usart0 port works (inside
the at91sam7s256), it seems that there is a hardware problem with the
circuit from the pins of the microcontroller to the DB9 port. NOW, my
question is, do i'm missing something? or it is definitely a hardware
problem and the board has to be changed.
I have reviewed the schematics, the configuration in the program, and
everything seems to be fine, and even works, like it showed the 3rd test. So
i doubt is a software error.
One detail i saw is that in the tutorial from p Lynch, he shows the
multiplexing table where it says that the RXD0 and TXD0 are in PA0 and PA1,
BUT in the at91sam7s256 datasheet and at91sam7s-ek user guide i downloaded,
it shows that the RXD0 and TXD0 are actually in PA5 and PA6. So i tested
with the two configurations and none of them worked. Fearing that maybe the
usart was in other pins (and not knowing what else could be wrong), i
disabled all 32 PIOs and set the peripheral A for the 32 lines. I ran the
4th test, and again the computer received nothing.
By the way, all jumpers were closed.
So, any idea what could be wrong?, do i have to change my board?
Thanks to all!
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1136 / Virus Database: 426/3298 - Release Date: 12/05/10
the data rate isn't correct (if it's much too fast or slow then the PC may
not report even garbage). And what have you dont with the PC flow control -
if DSR isn't avtive then the PC will probably ignore all input. Try looping
back DTR/DSR and RTS/CTS (pins 4,6 and 7,8).
Cheers,
Frog
_____
From: A... [mailto:A...] On Behalf Of
d...@gmail.com
Sent: Monday, 6 December 2010 11:46 a.m.
To: A...
Subject: [AT91SAM] USART0 AT91SAM7S-EK
Hello there! I've been working on my new AT91SAM7S-EK and the USART0. I'm
following the AT91SAM7S256 Serial Communications tutorial from James P.
Lynch and i've had some problems to make it work. To connect my board with
the computer and send/receive data, i used an USB/serial cable (pl2303) and
the program "realterm". To see where was the problem i ran the next tests:
1.- Channel mode normal. I activated the TXEMPTY interrupt to send data
infinitely to my computer. Result: nothing was received in the realterm
program (not even garbage). I know the TXEMPTY interrupt was met because
before it sends something with US_THR inside this interrupt, it makes the
LED_D (or LED4 whathever you name it) "on" for a second and then off for
another second and then sends the one-byte data. So, the target started
sending a byte each two seconds to my computer, but as i say, the realterm
got nothing.
2.- Channel mode normal. I activated the RXRDY interrupt to receive data. To
know if this interrupt is met, i set the program to turn on the LED_C when
the target received data. Result: The interrupt was never met, so mu board
never got the data i sent by the realterm.
3.- Channel mode local loopback. I left RXRDY and TXEMPTY interrupt
activated, each one with a 1 second blink with delay (RXRDY with LED_C and
TXEMPTY with LED_D) so to know if the interrupts where met. Result: The
USART0 worked nice! The two interrupts where met. LED_C and LED_D where
blinking intermittently; this meant that at least, internally, the
at91sam7s256's USART0 was working without problems. I even tested if if it
was receiving the correct characters that was sending, and that test worked
too.
4.- Channel mode remote loopback. Configured like this, i understand that if
i send data, it goes from my computer to the DB9 port, then the st3232 chip,
then enters to the pin of the at91sam7s256 (RXD0) and internally this pin is
connected to the TXD0, so the same data gets back by this pin to the st2323
chip, then the db9 port and finally the computer. Result: The realterm sent
data but never got it back.
So im getting to the conclusion that although the usart0 port works (inside
the at91sam7s256), it seems that there is a hardware problem with the
circuit from the pins of the microcontroller to the DB9 port. NOW, my
question is, do i'm missing something? or it is definitely a hardware
problem and the board has to be changed.
I have reviewed the schematics, the configuration in the program, and
everything seems to be fine, and even works, like it showed the 3rd test. So
i doubt is a software error.
One detail i saw is that in the tutorial from p Lynch, he shows the
multiplexing table where it says that the RXD0 and TXD0 are in PA0 and PA1,
BUT in the at91sam7s256 datasheet and at91sam7s-ek user guide i downloaded,
it shows that the RXD0 and TXD0 are actually in PA5 and PA6. So i tested
with the two configurations and none of them worked. Fearing that maybe the
usart was in other pins (and not knowing what else could be wrong), i
disabled all 32 PIOs and set the peripheral A for the 32 lines. I ran the
4th test, and again the computer received nothing.
By the way, all jumpers were closed.
So, any idea what could be wrong?, do i have to change my board?
Thanks to all!
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1136 / Virus Database: 426/3298 - Release Date: 12/05/10
Reply by ●December 6, 20102010-12-06
Typical SW guys: always blaming the hardware.. :)
It's unlikely the -EK board has a hardware problem. Board configuration problem: maybe. Improper/incomplete UART/PIO configuration in the SAM7: probably.
First, make sure your serial cable is working properly. Short pins 2 & 3 of the serial cable together when it is not connected to anything and check that the terminal program you're using sees echoed characters when you type something. If it isn't working, make sure hardware flow control is turned off.
If you're using Windows 7, you may need to look for a different serial cable. So far I haven't found a PL2303 driver that's stable under Win 7. Some will work for awhile, but they eventually lock up or blue screen.
If the cable is working, switch to polled mode in the serial driver on the -EK and make sure you can transmit and receive characters.
If that's all working, then your problem is something in your software. There's a fair amount of configuration necessary before you can send/receive characters with these processors.
Cliff
--- In A..., dragonflyluis@... wrote:
>
> Hello there! I've been working on my new AT91SAM7S-EK and the USART0. I'm following the AT91SAM7S256 Serial Communications tutorial from James P. Lynch and i've had some problems to make it work. To connect my board with the computer and send/receive data, i used an USB/serial cable (pl2303) and the program "realterm". To see where was the problem i ran the next tests:
>
> 1.- Channel mode normal. I activated the TXEMPTY interrupt to send data infinitely to my computer. Result: nothing was received in the realterm program (not even garbage). I know the TXEMPTY interrupt was met because before it sends something with US_THR inside this interrupt, it makes the LED_D (or LED4 whathever you name it) "on" for a second and then off for another second and then sends the one-byte data. So, the target started sending a byte each two seconds to my computer, but as i say, the realterm got nothing.
>
> 2.- Channel mode normal. I activated the RXRDY interrupt to receive data. To know if this interrupt is met, i set the program to turn on the LED_C when the target received data. Result: The interrupt was never met, so mu board never got the data i sent by the realterm.
>
> 3.- Channel mode local loopback. I left RXRDY and TXEMPTY interrupt activated, each one with a 1 second blink with delay (RXRDY with LED_C and TXEMPTY with LED_D) so to know if the interrupts where met. Result: The USART0 worked nice! The two interrupts where met. LED_C and LED_D where blinking intermittently; this meant that at least, internally, the at91sam7s256's USART0 was working without problems. I even tested if if it was receiving the correct characters that was sending, and that test worked too.
>
> 4.- Channel mode remote loopback. Configured like this, i understand that if i send data, it goes from my computer to the DB9 port, then the st3232 chip, then enters to the pin of the at91sam7s256 (RXD0) and internally this pin is connected to the TXD0, so the same data gets back by this pin to the st2323 chip, then the db9 port and finally the computer. Result: The realterm sent data but never got it back.
>
> So im getting to the conclusion that although the usart0 port works (inside the at91sam7s256), it seems that there is a hardware problem with the circuit from the pins of the microcontroller to the DB9 port. NOW, my question is, do i'm missing something? or it is definitely a hardware problem and the board has to be changed.
>
> I have reviewed the schematics, the configuration in the program, and everything seems to be fine, and even works, like it showed the 3rd test. So i doubt is a software error.
>
> One detail i saw is that in the tutorial from p Lynch, he shows the multiplexing table where it says that the RXD0 and TXD0 are in PA0 and PA1, BUT in the at91sam7s256 datasheet and at91sam7s-ek user guide i downloaded, it shows that the RXD0 and TXD0 are actually in PA5 and PA6. So i tested with the two configurations and none of them worked. Fearing that maybe the usart was in other pins (and not knowing what else could be wrong), i disabled all 32 PIOs and set the peripheral A for the 32 lines. I ran the 4th test, and again the computer received nothing.
>
> By the way, all jumpers were closed.
>
> So, any idea what could be wrong?, do i have to change my board?
>
> Thanks to all!
>
It's unlikely the -EK board has a hardware problem. Board configuration problem: maybe. Improper/incomplete UART/PIO configuration in the SAM7: probably.
First, make sure your serial cable is working properly. Short pins 2 & 3 of the serial cable together when it is not connected to anything and check that the terminal program you're using sees echoed characters when you type something. If it isn't working, make sure hardware flow control is turned off.
If you're using Windows 7, you may need to look for a different serial cable. So far I haven't found a PL2303 driver that's stable under Win 7. Some will work for awhile, but they eventually lock up or blue screen.
If the cable is working, switch to polled mode in the serial driver on the -EK and make sure you can transmit and receive characters.
If that's all working, then your problem is something in your software. There's a fair amount of configuration necessary before you can send/receive characters with these processors.
Cliff
--- In A..., dragonflyluis@... wrote:
>
> Hello there! I've been working on my new AT91SAM7S-EK and the USART0. I'm following the AT91SAM7S256 Serial Communications tutorial from James P. Lynch and i've had some problems to make it work. To connect my board with the computer and send/receive data, i used an USB/serial cable (pl2303) and the program "realterm". To see where was the problem i ran the next tests:
>
> 1.- Channel mode normal. I activated the TXEMPTY interrupt to send data infinitely to my computer. Result: nothing was received in the realterm program (not even garbage). I know the TXEMPTY interrupt was met because before it sends something with US_THR inside this interrupt, it makes the LED_D (or LED4 whathever you name it) "on" for a second and then off for another second and then sends the one-byte data. So, the target started sending a byte each two seconds to my computer, but as i say, the realterm got nothing.
>
> 2.- Channel mode normal. I activated the RXRDY interrupt to receive data. To know if this interrupt is met, i set the program to turn on the LED_C when the target received data. Result: The interrupt was never met, so mu board never got the data i sent by the realterm.
>
> 3.- Channel mode local loopback. I left RXRDY and TXEMPTY interrupt activated, each one with a 1 second blink with delay (RXRDY with LED_C and TXEMPTY with LED_D) so to know if the interrupts where met. Result: The USART0 worked nice! The two interrupts where met. LED_C and LED_D where blinking intermittently; this meant that at least, internally, the at91sam7s256's USART0 was working without problems. I even tested if if it was receiving the correct characters that was sending, and that test worked too.
>
> 4.- Channel mode remote loopback. Configured like this, i understand that if i send data, it goes from my computer to the DB9 port, then the st3232 chip, then enters to the pin of the at91sam7s256 (RXD0) and internally this pin is connected to the TXD0, so the same data gets back by this pin to the st2323 chip, then the db9 port and finally the computer. Result: The realterm sent data but never got it back.
>
> So im getting to the conclusion that although the usart0 port works (inside the at91sam7s256), it seems that there is a hardware problem with the circuit from the pins of the microcontroller to the DB9 port. NOW, my question is, do i'm missing something? or it is definitely a hardware problem and the board has to be changed.
>
> I have reviewed the schematics, the configuration in the program, and everything seems to be fine, and even works, like it showed the 3rd test. So i doubt is a software error.
>
> One detail i saw is that in the tutorial from p Lynch, he shows the multiplexing table where it says that the RXD0 and TXD0 are in PA0 and PA1, BUT in the at91sam7s256 datasheet and at91sam7s-ek user guide i downloaded, it shows that the RXD0 and TXD0 are actually in PA5 and PA6. So i tested with the two configurations and none of them worked. Fearing that maybe the usart was in other pins (and not knowing what else could be wrong), i disabled all 32 PIOs and set the peripheral A for the 32 lines. I ran the 4th test, and again the computer received nothing.
>
> By the way, all jumpers were closed.
>
> So, any idea what could be wrong?, do i have to change my board?
>
> Thanks to all!
>
