arantius.com

A Quick RFID Hack

2016-12-11 16:01 - Making

I recently became interested in an RFID-based project. In actuality, revamping an existing project incorporating RFID reader(s). In truth, the application wants five separate cards in five separate (nearby) locations to be readable at roughly the same time. Today they're using what appears to be a RDM630 module, with some electronics to switch in five separate antennas, and this is slow. (Power down, switch in an antenna, power up, wait long enough to be sure the card would answer if it was there, power down, switch in the next antenna, repeat x5.) It would be very nice if it was more responsive.

The thing is that the RDM630 is a "no name" brand product, with documentation scattered and spotty at best. What they've got in common is a set of three headers. On the main five pin header: two of the pins are power, one is unused, and the other two are consistently labeled as the TX/RX pair for a UART. A two pin header goes to the antenna, and a third is both the power and signal line to drive an LED indicator.

These RDM630 modules all speak 9600 baud UART, and for my application the problem is that they all simply output the ID of the card exactly once, when it appears in range. I can't control that timing, so I'd need to be prepared to read from five separate readers all at once. It's not easy to have five UART inputs all working in parallel with independent timing. But there's an RX pin labeled in addition to the TX pin, might it be possible to put these things into a mode where they could be queried on demand, with timing I can control?

These modules appear to be an implementation of a common design for low frequency RFID readers floating around the internet: a microcontroller, an op amp, and some glue. There's no reason that the microcontroller couldn't be programmed with further abilities. But I can't find any word anywhere about what they are, if they exist.

There's also a related module with the same footprint called the RDM6300, with at least two variants. One of them has an extra four-pin header compared to the otherwise common pinout, in the top middle in the picture just above. I managed to convince myself, by pictures available online, that I knew this was the debugging port for the microcontroller. In these variants it was always a Silicon Labs F330, an 8051 variant. So I got one of these RDM6300 modules, and found a cheap SiLabs USB Debug Adapter from eBay. My goal was to dump the code and discover more about how it works, especially if there is an existing way to ask it to behave differently over UART.

Before I continue, for posterity the pins are (from left to right starting at the square one in the picture above): 1 GND, 2 Vdd, 3 C2CK, 4 C2D, which are the power and debug pins for the SiLabs C0851F330 microcontroller (see page 37). All of the pins besides GND lead to vias, but they're trivial to trace through the other side of the board to the vias that pop back to this side of the board where the microcontroller is. It's got pin one on bottom left, and the bottom right three are the three pins in question (besides GND). Note that it's a 3.3 volt part, the regulator is right next to it which drops the 5V "normal input"; this part is also 5V tolerant on all its pins.

I have dumped the flash, and disassembled it. The disassembly seems imperfect, especially all the addresses in the middle of instructions. But there is clearly:

X0db1:  mov     sbuf,r7         ; 0db1   8f 99      ..
X0db3:  jnb     ti,X0db3        ; 0db3   30 99 fd   0.}
        clr     ti              ; 0db6   c2 99      B.
        ret                     ; 0db8   22         "
;

Exactly one place that the sbuf register is referenced, and it seems pretty clear to be a "write the byte in R7 to the serial buffer (memory mapped) "register", loop until the transmit bit is set, clear it, return" routine, which makes total sense for a UART transmission. There is no corresponding read from sbuf, so the default firmware will not, for example, respond with the ID when queried over the UART. This write-to-UART routine appears to be called (lcall X0db1) in three places, all within 20 instructions from each other.

In theory perhaps I could patch the firmware to put such functionality in at this point, but there are challenges. First would be writing such code, in assembler. I could probably write it in C, compile that, and get the assembler that way. Then I'd have to insert it into the current firmware somehow which is even more difficult. Where is the main loop? How do I insert it without breaking existing functionality? And how do I fit it? The dump I've got is 7,681 bytes of a theoretical 7,678 maximum, and the clearly empty bit at the end starts at 7,603, leaving only a tiny bit of space.

In the mean time I've found the MFRC522. It operates on a different kind of RFID tag, but already supports the sort of slave mode "speak only when spoken to" protocol that makes it easy to interface with several at the same time, so I'm continuing by working in that direction.