TRF7970A: EN and EN2 inputs permanently connected to main power

Hello Ralph,

Thanks for support via Alberto's question. I would like to test (like the first step) just communication between my system and TRF7970A over SPI.

What register I can write/read to verify just functionality of SPI bus ? This is my first step to verify communication - before setting up the RFID chip.

Thanks,

Ondrej

Hello Ralph,

it works. I have already verified my SPI communication reading some registers. That is OK.

Another step is reading Inventory on my RFID tag. It uses ISO 15563 standard. Im trying to fill-in registers correctly, but I'm not sure with correct settings. So, what registers and what steps must be done to be able read Inventory on my RI-IO3-112A-03 ?

I have already downloaded program TRF7970A_EVM_GUI.exe (2781184 bytes lenght) and RFIDread Win 7.exe (7887360 bytes), but I have issues with running them on Win 7. In case I connect TR7970A EVM board into USB and COM port e.g. 11 or 35 is assigned, after pressing "Set Protocol" button is program frozen. I tried 32 and 64 bit windows 7 - the same behaviour.

Output from log file, the EVM board used COM11, after crashing I remapped the com port to COM2 - no success. I don't understand, why Select port button is not working...

11:10:47.255    COM12
11:10:47.257    COM11
11:10:47.258    COM10
11:10:47.259    COM9
11:10:47.259    COM8
11:10:47.260    COM7
11:10:47.261    COM6
11:10:47.261    COM5
11:10:47.262    COM4
11:10:47.263    COM3
11:10:47.264    COM2
11:10:47.265    COM1
11:10:47.279    --> 0108000304FF0000
11:10:49.387    *** Read TIMEOUT ***
11:10:49.407    COM0
11:10:53.349    --> 010A0003041001210000
11:10:53.363    COM1
11:11:35.890    *** Read TIMEOUT ***
11:11:35.902    --> 010C00030410002101000000
11:12:18.416    *** Read TIMEOUT ***
11:12:18.429    --> 0109000304F0000000
11:13:00.944    *** Read TIMEOUT ***
11:13:00.948    --> 0109000304F1FF0000
11:13:43.454    *** Read TIMEOUT ***
11:13:43.477    --> 010B000304140401000000
11:14:25.992    *** Read TIMEOUT ***

Hello Ondrej,

That's an odd situation with the EVM. I can say that COM11 rarely has worked even though the GUI says it tries for that so you'll want to avoid that one - that is why the program reports the Missing COM port. You could also try other ports like COM3 or COM4 in case something weird got hosed up with COM2. When doing so, make sure the GUI is closed. Another option would be to restart your PC to free up the list of COM ports, and then re-plug the EVM in, make sure it enumerates to a low power (COM2-5 range) and then try the GUI again.

I'm not sure when the last time I tried to build the GUI was, again at this point we consider it an obsolete EVM so while I can offer advice on how to try and make it operate, we aren't investing any time in looking into any bugs.

As far as scoping the SPI bus, again since that software is not the latest and has bugs, I wouldn't recommend relying on it to do that. This hardware package will work with SLOC297 firmware, that'd be better to use for SPI bus scoping:

Hello Ralph,

thanks again for your support. I'm trying to undertstand source code in SLOC297 bundle, because I'm porting it to ESP32 platform. That means, I have to study, how it works - part for ISO15693. One part of code I don't understand - I know, that TRF7970A generates IRQ signal after receiving command for Inventory and it generates IRQ when data are ready in FIFO buffer. But, looking into "trf79xxa.c" and "iso15693.c" file, I see calling functions waiting for IRQ inside function "TRF7970A_waitRxData"

   case TX_WAIT:
      TRF7970A_waitTxIRQ(ui8TxTimeout);      // TX timeout
      TRF7970A_waitRxIRQ(ui8RxTimeout);      // RX timeout
      break;

With following parameters in "ISO15693_sendSingleSlotInventory" -

g_sTrfStatus = TRF7970A_waitRxData(5,15);

But, looking into SPI bus sniffed by scope - IRQ signal after sending Inventory command (TX) is active approx. after 4.5ms, OK, but IRQ confirming RX is after 50ms after TX IRQ. When both functions for IRQ signal follows in order, there MUST BE timenout generated - RX timeout is set just for 15ms in SLOC297 example. I dont have the TRF7970A BNDL, could somebody verify functionlality of your demo code for TI RFID tag ISO15693 with Inventory command ? - especially IRQ timing ?

Thanks,

Ondrej

Hello Ralph,
I'm little bit further now :)
I have ordered original DLP-7970ABP module and I'm adapting SLOC297 firmware to Arduino.
Reading is working very well. But writing...

I'm using funtion uint8_t ISO15693_sendWriteSingleBlock(uint8_t ui8ReqFlag, uint8_t ui8BlockNumber, uint8_t ui8BlockSize, uint8_t * pui8BlockData)

What is not clear for me is ui8ReqFlag. There is not too much explanation, what is structure of this variable/tag. Could you be more specific ?
When I try to write to my tag, flag is defined. 0x40 must be set - looking into source code - it announces writing operation
uint8_t ui8AddressedFlag = B01100010;
but after writing the first sequence, the data are in the tag - verified by reading - but I receive [01 13] response, what is probably "Programming was unsuccessful" - TRF 7960 Evaluation module (ISO 15693 Host commands) PDF file - page 23.

Could you explain me, what is the reason of this answer or explain me detailed structure of TRF7970A buffer for writing single address ?

Thanks,
Ondrej

Hi Ralph,

thanks for explanation. But, still don't know, why my write command is not successful.

I'm sending to TRF7970A with UID "E00700002187FC25" following sequence (verified on logic analyzer )

MISO: 8F 91 3D 00 F0 62 21 25 FC 87 21 00 00 07 E0 00 10 D0 CD AA - is should be request for writing 10 D0 CD AA to block 00

answer is

IRQ -> confirming TX

MISO 4C 00 5C 00 7F 00 00 8F

MOSI 00 40 00 02 00 01 13 00

IRQ -> confirming RX

MISO 4C 00 5C 00 7F 00 00 8F

MOSI 00 40 00 02 00 01 13 00

I tried flag byte 0x22 instead of 0x62, also 0x20 for lower speed - no success.

Why the answer is not 00 -> OK, but 01 13 - Programming was unssuccesful. What can be wrong ?

Thanks,

Ondrej

after the first IRQ

after the second IRQ

Ralph,

just for my info - how to lock and unlock some block in RF-TAG ? Maybe, I have locked the RFID tag and it is the reason, why I can't write to the memory block. But I don't know how to obtain info, if some block is locked or not. What is the commend or method to unlock it ?

SPI bus screenshot for flag 0x22 I will send tomorrow, but I expect the same behavior. System reports Status = 0x09, what means  NO_RESPONSE_RECEIVED_15693

I will investigate it tomorrow. Just I would like to be sure to eliminate situation with locked RFID tag memory.

typedef enum
{
    TRF_IDLE,                    // New
    TX_COMPLETE,                // Formally 0x00
    RX_COMPLETE,                // Formally 0xFF
    TX_ERROR,                    // New
    RX_WAIT,                    // Formally 0x01
    RX_WAIT_EXTENSION,            // New
    TX_WAIT,                    // New
    PROTOCOL_ERROR,                // Formally 0x02
    NO_RESPONSE_RECEIVED,        // Formally 0x00
    NO_RESPONSE_RECEIVED_15693     // Added for 15693 cases.
}tTRF797x_Status;

Thanks,

Ondrej

Hello Ondrej,

Few points on that topic:

1. Lock block cannot be undone, it is permanent.
2. A tag with a locked block will reply with an error code indicating the block is locked, that is defined by ISO15693 as error code 0x12.
3. Lock block command is not something I included in the RFID reader code because of how powerful and irreversible it is, so if the tag got locked, it was from some other RFID reader.

By the way, getting NO_RESPONSE_RECEIVED_15693 should only occur during Anticollision based on how the firmware is structured as it is only used for the No Response Interrupt from IRQ that is disabled by default and only used for the ISO15693 anticollision algorithm.

Hello Ralph,

I did measurement again today. The reality is, although there is error code after operation, the requested value is recorded in the tag. But, I'm still worried about the error code after writing operation.

The first picture - request to writing to segment 0x00 with flag 0x22

the first response is IRQ confirming TX + clear FIFO request

Now, what is not visible, is send 0x94, actually command 0x14 and the second IRQ - RX - is received following error code 0103

The second try is with flag 0x62 - there is also error reported at the end, but it is different error. See the request, if it is correct.

confirming TX operation by IRQ, following with clear FIFO request

and last IRQ confirming RX, see different reported error code. There is also sent 0x94 after TX IRQ (not visible on the picture)

See different error code. For 0x22 flag it was 0103, for 0x62 flag it is 0113

Las picture shows whole sequence with timing - sending 0x94 code between TX and RX IRQ - approx. 497.1ms

The question is, what I'm doing wrong, that after Single write (0x21 command) sequence I receive mentioned errors ? The time delay difference between 0x22 and 0x62 flag option is caused by program structure - fixed value 0x22 and variable with 0x62.

I tried to find some more info about ISO15693 regarding communication between chip and tag, I'm getting info from SLO141, but is related to host command (software in MSP micro), not direct communication with TRF7970A.

Thanks,

Ondrej

Ralph,
I'm not sure, but you probably looked into bad pictures - there are 7 pictures in my last contribution. The first three pictures are with flag 0x22 - response is 01 03, next 3 pictures are with flag 0x62, the response is 01 13 and the last picture is overall picture with whole sequence to verify timing. In picture 4 you can see flag 0x62 - located on the red line, picture 6 shows FIFO response 00 01 13

Ondrej

Ralph,

looking to picture 7 of my post with SPI screenshots, the TX IRQ signal is received at 492ms, 0x94 is send at 497.2ms - it means approx. 5ms.

Ondrej

Hello Ralph,

don't know why, but I used different waiting method in Arduino code than expected "delay(10)" comparing TRF7970A original source code for MSP.

After replacing original waiting command with delay(10) command it works perfectly now. So the issue was with short time.

Thanks for your help.

Ondrej