CARD_READER.LIB and PORT D

Hello all,

I am currently trying to interface a Magtek magnetic card reader to my RCM3200 module via parallel port D. I am simply trying to test the circuit using the CARD_READ_TEST.C provided in the Dynamic C samples dir. First of all, if I don’t define CR_USEPORTD, it seems to default to PORT G, which is the opposite of the behavior I would expect from looking at CARD_READER.LIB. When I do define CR_USEPORTD, the library fails (program exits unexpectedly) in CRinit(), seemingly on the following line:

WrPortI(ICS2R, NULL, 0x76);

which is called when READER_TRACKS is defined at 2 or greater. So yes, if I define only a single track, CRinit() does not fail. However, the program simply waits for card swipe indefinitely, obviously not picking up the card swipes I’m performing.

I’ve double and triple checked the connections, and things look correct. I’ve also tried connecting the device to PORT G instead, and got output when I swiped cards. (but decoding failed) I’m using the 32xx prototype board, which shows PORT D unused for any circuitry on the board. (leaving it available for me to use, presumably)

Has anyone else out there tried using PORT D with the card reader library? It should be straightforward, I would think, from reading the docs, (I’ve read through the code and AN233) but something is clearly not working. I can’t use PORT G because I’m using it for serial ports E and F.

Anyway, thanks for any help!


Jon

Hello all,

I haven’t yet resolved my problem getting the CARD_READER.LIB library working on PORT D with my Magtek P-series TTL magnetic card reader. I do, however, have some more info to share from my attempts to troubleshoot the issue.

I managed to find another card reader library from the Yahoo Rabbit Semi group’s download area. This library actually just looks like an older incarnation of the CARD_READER.LIB currently shipping with DC 9.50. While there are a number of function/variable name changes, the most interesting differences between this older library and the current library are the values used to initialize the input capture module and, consequently, the values used in the ISR.

In the latest CRinit(), ICS1R is set with the value of 0x54, which corresponds to the following behavior (according to the R300UM):

  • Use Parallel Port D for Start Condition
  • Use port bit 3 for Start Condition (Track 1 Strobe)
  • Use Parallel Port D for Stop Condition
  • Use port bit 1 for Stop Condition (Card Present)

With this configuration (meant for capturing track 1 data), I get no response when swiping a card. However, if I use the value 0x45, from the older version of the library, the ISR is called and I get a response. (though decoding still fails. This is presumably due to another bit mismatch in the ISR I have yet to track down.) The 0x45 value reverses the start and stop condition bits, and again, this seems to be a step in the right direction for me.

As for the value of ICS2R, the latest library sets this to value 0x76:

  • Use Parallel Port D for Start Condition
  • Use port bit 7 for Start Condition (Track 3 Strobe)
  • Use Parallel Port D for Stop Condition
  • Use port bit 5 for Stop Condition (Track 2 Strobe)

When I tracked this down, I realized that I’m not supplying track 3 signals at all, as this is a 2-track reader. I’m now using 0x56 as my initialization value for ICS2R:

  • Use Parallel Port D for Start Condition
  • Use port bit 3 for Start Condition (Track 1 Strobe)
  • Use Parallel Port D for Stop Condition
  • Use port bit 5 for Stop Condition (Track 2 Strobe)

So far, this setup produces some Track 2 data (not sure if it’s right, yet) and does not lock up my program like the values 0x76 or 0x67 (from older, Yahoo forum-provided library) did.

Assuming I’m onto something here with the values of the ICSxR regs, I’m moving on to the asm ISR code to determine how these changes affect the reading of the actual data in the ISR.

So anyway, I put all this info here in the hopes it might be helpful either to someone who wishes to help me resolve this issue, or perhaps even helpful to someone else with the same problem.

Can anyone (from Rabbit?) comment on the differences between the Yahoo forum card reader library and that included in DC 9.50? Am I making appropriate assumptions in my alteration of values as described above? Is there perhaps something I am missing here?

Oh, and something new: This Magtek reader provides a “Back Sensor” signal - “Active low when the card is at the rear of the unit”. As this is an insertion-style reader, Magtek apparently recommends only reading the swipe on the outbound swipe, as it is more accurate. Has anyone else used something like this before with the Rabbit? How might I go about incorporating this signal?

Thanks again,
Jon

Hello all,

I just wanted to report that I have resolved my issues and I now have a functional magnetic stripe reader connected to my RCM3200 board.

I had apparently overlooked a note in the RCM3200 User Manual that stated that the connections PD2, PD3, PD6 and PD7 were not connected on the module and were reserved for future use. (Figure 6. of the RCM3200 UM also shows only PD4 and PD5 available)

I was unfortunately confused by the availability of PD0-PD7 pins marked on the RCM30/31/32xx prototype board.

The CARD_READER.LIB only lists PORTS D and G as available for use, but in my research I discovered that the Input Capture modules are also available to use with Parallel ports C and F. As ports C and G were tied up for serial comms, and D was now unavailable, I was left with PORT F. I simply translated the connections for the card reader to PORT F and made several appropriate changes to the CARD_READER.LIB to point the Input Capture module at the correct port. I also made one change to the ISR in the library.

Anyway, I just thought I’d share this with you all, that you can, in fact, use the CARD_READER.LIB on ports C and F, with some slight modification.

I’ll try to post a patch for CARD_READER.LIB soon.

Thanks,
Jon

Hey all,

I’m posting this patch file I made for the CARD_READER.LIB file from the Dynamic C 9.50 distribution. It adds support for using the library on parallel ports C and F, in addition to D and G. I have personally tested this patch on port F, but not C, so YMMV.

I also added support for using the back sensor signal provided on insertion style card readers. It should be connected to bit 0 of the chosen port. Included in the patched library is a function for checking the status of this sensor.

I hope someone else finds this patch useful. Rabbit folks, if this looks good, you’re welcome to add it to the distributed library.


Jon

Thanks Jon,

I will take a look at your changes. Glad you got it working.