Meindert Sprang wrote:
> "galapogos" <goister@gmail.com> wrote in message
> news:1162398447.330815.40370@m73g2000cwd.googlegroups.com...
> > 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.
>
> That's because the ISO7816-10 (not -3) specifies the signals on the card.
> How you physically connect to the card is beyond the spec. The "card-loaded"
> or whatever name is used, is a signal from a switch or opto thingy on a card
> reader assembly and is surely part of your ghetto reader as well.
>
> Meindert
Hmm, I only have the iso7816-1 to iso7816-4 documents. I googled
iso7816-10 and the title for that is "ISO7816-10 Identification Cards-
Integrated circuits card with contacts. Part 10 : Electrical Interface
for synchronous cards".

Does this only apply to synchronous cards? I'm using the asynchronous
T=0 protocol so I'm not sure if it applies to me.

"galapogos" <goister@gmail.com> wrote in message
news:1162398707.853745.162010@i42g2000cwa.googlegroups.com...
> 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.

Ah, sim card holders generally do not have a "card-loader" signal. I was
talking about the things where you slide in a creditcard-size smartcard.
Generally, sim card holders are not meant for regular insertion/extraction
and surely not when powered.

Meindert

"galapogos" <goister@gmail.com> wrote in message
news:1162398447.330815.40370@m73g2000cwd.googlegroups.com...
> 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.

That's because the ISO7816-10 (not -3) specifies the signals on the card.
How you physically connect to the card is beyond the spec. The "card-loaded"
or whatever name is used, is a signal from a switch or opto thingy on a card
reader assembly and is surely part of your ghetto reader as well.

Meindert

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.

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.

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

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.

"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

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.

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.