UART receive ISR receives 1st 2 bytes twice

Jim Granville wrote:
> galapogos wrote:
> > Jim Granville wrote:
> >
> >>galapogos wrote:
> >>
> >>>Hi,
> >>>
> >>>I'm trying to read data from a smart card via a Toshiba 16bit MCU's
> >>>UART interface set at a slow 4+K baudrate. My receive ISR however seems
> >>>to pull out the 1st 2 bytes of the transmission from the receive buffer
> >>>twice. i.e., when the smart card sends 0x1, 0x2, 0x3, ..., 0xa, My
> >>>receive ISR will receive 0x1, 0x2, 0x1, 0x2, 0x3, ...,0xa. I've checked
> >>>the I/O line with a logic analyzer and the smart card isn't resending
> >>>the 1st 2 bytes. I've checked the bit period on both the MCU and smart
> >>>card and they both agree(i.e. similar baudrate) so it's not a
> >>>synchronization problem either.
> >>
> >>Step back a bit, and think "How does the INT routine 'know' it is the
> >>first bytes" ?
> >>What makes that different from other bytes, and why should it _stop_
> >>doing this ?
> >>
> >>Create your own test data stream, and try that ?
> >>
> >>-jg
> >
> >
> > That's what I'm wondering too. How does the isr know, when actually the
> > logic analyzer shows no such repeat? And, why does it only happen when
> > the smart card is plugged in right before the transmission begins?
>
> Does this uC have any comms error flags ?
> [things covering errors like False start bits, framing error etc ? ),
>
> > I've thought about creating my own test data stream so I can isolate it
> > without relying on smart card transmissions, but how would I create the
> > test data stream to send it to the UART though? Wouldn't I need some
> > external device with another UART to do so?
>
> Yes, just another of the PCB you are working on, with small test code ?
>
> -jg

The mcu does have parity, framing and overrun error flags, but for the
purpose of testing, i'm currently not checking these. The baudrate I'm
using is so slow(~5000bps) that such errors would be very unlikely, and
the waveform I'm seeing on my logic analyzer seems to confirm this.

Unfortunately I only have 1 prototype pcb and 1 mcu emulator.
Interfacing it with another board will require me to make another pcb
and obtain another emulator from the vendor, which is pretty
inconvenient.

"galapogos" <goister@gmail.com> wrote in message
news:1162361089.252354.173920@k70g2000cwa.googlegroups.com...
> The mcu does have parity, framing and overrun error flags, but for the
> purpose of testing, i'm currently not checking these. The baudrate I'm
> using is so slow(~5000bps) that such errors would be very unlikely, and
> the waveform I'm seeing on my logic analyzer seems to confirm this.

But when you insert the card while the software is running, all sorts of
rubbisch might be received due to contact bounce, producing framing, overrun
and parity errors. So the first two interrupts might well be caused by this.
The solution is that right before you start issueing commands to the card,
you clear the receiver status and empty the fifo first. Do this before each
command sent or only the first time you detect a card (you do have a card
detection signal, do you?).

Meindert

galapogos wrote:

> Anyway, I discovered that when I connect my smart card before program
> execution, I don't get the repeated bytes problem, but when I run it to
> a breakpoint right before resetting the smart card(and getting back
> some ack data from the smart card) and THEN connect the smart card
> before continuing the program, then I get the problem. Wonder why that
> would be the case.

Perhaps you can indicate the ISR activity by toggling a GPIO pin, and
see how the timing relates to the actual serial data being received on
your logic analyser.

Arlet wrote:
> galapogos wrote:
>
> > Anyway, I discovered that when I connect my smart card before program
> > execution, I don't get the repeated bytes problem, but when I run it to
> > a breakpoint right before resetting the smart card(and getting back
> > some ack data from the smart card) and THEN connect the smart card
> > before continuing the program, then I get the problem. Wonder why that
> > would be the case.
>
> Perhaps you can indicate the ISR activity by toggling a GPIO pin, and
> see how the timing relates to the actual serial data being received on
> your logic analyser.

That's exactly what I'm doing. I toggle 2 GPIO pin in my ISRs(rx and
tx) so I can tell how many bytes are being received and transmitted.
But it isn't that easy to trigger on the right transfers on the logic
analyzer.

Meindert Sprang wrote:
> "galapogos" <goister@gmail.com> wrote in message
> news:1162361089.252354.173920@k70g2000cwa.googlegroups.com...
> > The mcu does have parity, framing and overrun error flags, but for the
> > purpose of testing, i'm currently not checking these. The baudrate I'm
> > using is so slow(~5000bps) that such errors would be very unlikely, and
> > the waveform I'm seeing on my logic analyzer seems to confirm this.
>
> But when you insert the card while the software is running, all sorts of
> rubbisch might be received due to contact bounce, producing framing, overrun
> and parity errors. So the first two interrupts might well be caused by this.
> The solution is that right before you start issueing commands to the card,
> you clear the receiver status and empty the fifo first. Do this before each
> command sent or only the first time you detect a card (you do have a card
> detection signal, do you?).
>
> Meindert

I think you might be right. Currently I'm not doing any card detection
since I'm not sure how to do that. If I just leave card inserted or
insert it before the start of the program, all is fine. On the
insertion though I do notice some activity on the various pins on my
logic analyzer, which probably indicates some contact bounce.

"galapogos" <goister@gmail.com> wrote in message
news:1162392548.483986.282290@m73g2000cwd.googlegroups.com...
> I think you might be right. Currently I'm not doing any card detection
> since I'm not sure how to do that. If I just leave card inserted or
> insert it before the start of the program, all is fine. On the
> insertion though I do notice some activity on the various pins on my
> logic analyzer, which probably indicates some contact bounce.

You bet you have contact bounce during insertion!
Any decent cardholder has a "card-loaded" contact. Read this contact and
when it closes or opens (whatever indicates the card is present, wait
another 50ms to make sure no contact bounces anymore. Then clear the fifo,
reset any error status in the UART and only then you start sending commands
to the card.

Meindert

galapogos wrote:

> That's exactly what I'm doing. I toggle 2 GPIO pin in my ISRs(rx and
> tx) so I can tell how many bytes are being received and transmitted.
> But it isn't that easy to trigger on the right transfers on the logic
> analyzer

A trick that I often use is to generate a trigger in software. Since
you only have a problem with Rx, you could use 1 GPIO pin to indicate
an Rx interrupt, and the other one to create a trigger signal that is
only toggled when the ISR detects the first character of a message, or
when you  detect the duplicate bytes, or something like that.

In article <1162392548.483986.282290@m73g2000cwd.googlegroups.com>, 
goister@gmail.com says...
> 
> Meindert Sprang wrote:
> > "galapogos" <goister@gmail.com> wrote in message
> > news:1162361089.252354.173920@k70g2000cwa.googlegroups.com...
> > > The mcu does have parity, framing and overrun error flags, but for the
> > > purpose of testing, i'm currently not checking these. The baudrate I'm
> > > using is so slow(~5000bps) that such errors would be very unlikely, and
> > > the waveform I'm seeing on my logic analyzer seems to confirm this.
> >
> > But when you insert the card while the software is running, all sorts of
> > rubbisch might be received due to contact bounce, producing framing, overrun
> > and parity errors. So the first two interrupts might well be caused by this.
> > The solution is that right before you start issueing commands to the card,
> > you clear the receiver status and empty the fifo first. Do this before each
> > command sent or only the first time you detect a card (you do have a card
> > detection signal, do you?).
> >
> > Meindert
> 
> I think you might be right. Currently I'm not doing any card detection
> since I'm not sure how to do that. If I just leave card inserted or
> insert it before the start of the program, all is fine. On the
> insertion though I do notice some activity on the various pins on my
> logic analyzer, which probably indicates some contact bounce.
> 
> 
I think the error flags may be a part of your problem.
Some UARTS need the error bits cleared before the next byte comes in or 
strange things happen.  Like the interrupt isn't cleared and the ISR 
gets called again and again until the bits get cleared by you or, 
possibly, the next byte coming in.

                    Jim

Meindert Sprang wrote:
> "galapogos" <goister@gmail.com> wrote in message
> news:1162392548.483986.282290@m73g2000cwd.googlegroups.com...
> > I think you might be right. Currently I'm not doing any card detection
> > since I'm not sure how to do that. If I just leave card inserted or
> > insert it before the start of the program, all is fine. On the
> > insertion though I do notice some activity on the various pins on my
> > logic analyzer, which probably indicates some contact bounce.
>
> You bet you have contact bounce during insertion!
> Any decent cardholder has a "card-loaded" contact. Read this contact and
> when it closes or opens (whatever indicates the card is present, wait
> another 50ms to make sure no contact bounces anymore. Then clear the fifo,
> reset any error status in the UART and only then you start sending commands
> to the card.
>
> Meindert
Well, actually I'm using a ghetto smart card reader. Basically I took a
usb smart card reader, ripped out the pcb, desoldered the wires, and
soldered on my own connnection to my own dev board.

I don't recall any "card-loaded" contact on the iso7816-3 specs. There
are only 8 pins - Vcc, GND, I/O, RST, CLK, VPP(not used) and 2
RFU(reserve for future use), and in this case the RFUs are the USB
D+/D- signals.

galapogos wrote:
> Meindert Sprang wrote:
> > "galapogos" <goister@gmail.com> wrote in message
> > news:1162392548.483986.282290@m73g2000cwd.googlegroups.com...
> > > I think you might be right. Currently I'm not doing any card detection
> > > since I'm not sure how to do that. If I just leave card inserted or
> > > insert it before the start of the program, all is fine. On the
> > > insertion though I do notice some activity on the various pins on my
> > > logic analyzer, which probably indicates some contact bounce.
> >
> > You bet you have contact bounce during insertion!
> > Any decent cardholder has a "card-loaded" contact. Read this contact and
> > when it closes or opens (whatever indicates the card is present, wait
> > another 50ms to make sure no contact bounces anymore. Then clear the fifo,
> > reset any error status in the UART and only then you start sending commands
> > to the card.
> >
> > Meindert
> Well, actually I'm using a ghetto smart card reader. Basically I took a
> usb smart card reader, ripped out the pcb, desoldered the wires, and
> soldered on my own connnection to my own dev board.
>
> I don't recall any "card-loaded" contact on the iso7816-3 specs. There
> are only 8 pins - Vcc, GND, I/O, RST, CLK, VPP(not used) and 2
> RFU(reserve for future use), and in this case the RFUs are the USB
> D+/D- signals.

Oh and I forgot to mention, I'm using a smart card module in sim form
factor and taping it onto the contact points on the pcb's sim holder,
so there's no "card bounce" per se. The bounce is probably happening on
the connector side, which is some generic connector/pin that I soldered
onto both the smart card side and my dev board side.