This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TRF7960A: Problem with write single block

Other Parts Discussed in Thread: TRF7960, TRF7964A, TRF7960A, TRF7970A

Hi,

I have a problem with Write Single Block (both sending and not sending UID)

The command works fine and I am able to write a block but I do not receive expected IRQ so I am not able to understand if the write is correct.

I am using Plus tags of any sizes

This is the sequence:

- Send command (option flag active)

- 0xA0 irq received (do nothing and wait next irq)

- 0x80 irq received. Wait 70ms and "TransmitNextSlot" (waiting less than 70ms results in a collision). I get the same result if I do not "TransmitNextSlot"

- No other irq are received (I expect a 0x40 irq)... .but data is written correctly.

The code to send the command is:

uint8_t buffer[12+UID_LEN];
uint16_t data_size = 7;
uint8_t flags = TRF_FLAG_OPTION;
if (uid)
{
data_size += UID_LEN;
flags |= TRF_FLAG_ADDRESS;
}

buffer[i++] = 0x8f; // Reset FIFO
buffer[i++] = 0x91; // Send with CRC
buffer[i++] = 0x3d; // Continuous write starting from 1D (transmission length)
buffer[i++] = (uint8_t)(data_size >> 8); // Data size (high byte)
buffer[i++] = (uint8_t)(data_size << 4); // Data size (low byte)
buffer[i++] = flags; // Flags
buffer[i++] = command; // Command
if (uid)
{
for (uint8_t j=0; j<UID_LEN; j++) // Copy UID (inverted)
{
buffer[i++] = uid[UID_LEN-1-j];
}
}

buffer[i++] = block_address; // Address
buffer[i++] = command_buffer[dataIndex+0]; // Data
buffer[i++] = command_buffer[dataIndex+1];
buffer[i++] = command_buffer[dataIndex+2];
buffer[i++] = command_buffer[dataIndex+3];

SPI_WriteBuffer(buffer, 0, i);

Any ideas? Thank you.

Best Regards

Alessandro

  • hey -sorry for the delay - missed this one coming in - see below and compare to your system. This is done with 25mSec delay after clearing the FIFO, after the 0x80 (EOTX IRQ) - I suspect this is the step you are missing perhaps. Or check that your option flags match what ISO control register is set for, that trips up some folks commonly, too. 

    STEP 1. Send WSB Command, with option flag set and high tag data rate, 1 of 4 data coding chosen

    STEP 2. Get 0xA0 IRQ, handling

    STEP 3. Get 0x80 IRQ, handling, followed with reset of FIFO

    STEP 4. Wait >10mSec...in this case wait time was 25mSec, then send EOF/Slot Marker

    STEP 5. Get EORX IRQ, handle, read FIFO status, read FIFO to get back 0x00 (no error status)

  • Hi Josh,

    I realized now that high data rate flag is needed also for write commands. With that flag it works fine (also for lock command). Thank you.

    I have an additional question regarding write single block. 

    How can I manage failures writing on locked blocks?

    Looking to my tests, if I write on a locked block, the TRF seems to answer in the same way as the block is not locked (but it do not write in the block) so I cannot detect the failure.
    Moreover, on subsequent commands, TRF do not send any IRQ (I need to reset the module).

    Thank you in advance

    Best regards

    Alessandro

  • for any ISO15693 command, always make sure request flags match what ISO control register is set for. Writing and locking don't have to be done at high data rate, even though i personally don't see a point in using low data rate in a low power system like what is made with the TRF79xxA...i would just use it (high data rate) all the time. 

    anyway - if the tag block is locked and you try to write to it or lock it again, you should get back a two byte response that corresponds to ISO15693 error codes. 

    you can see the entire table of possible responses to all commands in section 8 (starts on page 13) here ==> (page 14 has line items for write single block and lock block error responses)

    if you can send over a logic capture of what command and procedure your code is doing when error occurs, most likely then we can see what is wrong. You should normally not have to reset the part to continue 

    thanks

  • Ok, thank you.
    I missed the error code part.
    Now I am able to detect errors on answer. I cannot still read the correct error code becouse I can find just 1 byte in FIFO (probably I make a dummy read that is needed for other commands but not here).

    I still have to reset the TRF before a write on a locked block becouse the TRF stop sending IRQ.
    I will try to log SPI but I do not have a data logger available now.
    In the meantime if you have any idea based on your experience please let me know.

    Thank you again.

    Alessandro
  • remember or realize with the TRF7960, 60A, -61, -62A and -63A that the FIFO status byte indicates the n-1 value, so if you are getting a 0x01 there, you have two bytes in FIFO to read out.
  • I know that FIFO status byte should indicate N-1 but, I do not know why, in my case it indicates always N (taking first 4 bytes).
    For example when I send a single block command I read 4 from FIFO status and not 3 as expected. The same for other commands.

    BR-

    Alessandro
  • I forgot to say that I read 2 from FIFO status in case I get a 2 byte error code
  • are you using a TRF7964A or TRF7970A instead of TRF7960A? Those devices indicate n value in FIFO status, different than -60, -60A, -61, -62A and -63A.
  • Our electronic engineer indicates TRF7960A in the wiring diagram. Tomorrow I will check directly in the test board but I suppose they cannot have used the wrong module.

    BR-

    Alessandro
  • I checked my test board and the module is the expected one. The text in the module is TRF 7960...
    Any other idea about the unexpected FIFO status value (software settings, timing, wiring...)?
    I am fighting from a while on this project because of unexpected behaviours. Now I am near the end but I still do not have everything working as expected so I would like to undestand if there are some mistakes in the base.
    Thank you for your help.

    BR-

    Alessandro

  • Please take the time to sit down with logic analyzer or o'scope and collect the communications between MCU and TRF

    then we can see what needs to be repaired in the FW> 

    thanks

  • Hi Josh,

    I am waiting an "usable" data logger so, in the meantime I collected sent/received bytes from MCU (even if it is not the same it can give some ideas)

    Following are (commented) log data for 4 commands (inventory 1 slot and 16 slots, read single block and write single block). Sorry if the text is a bit large.

    Red bytes are bytes from MCU to TRF7960 and green bytes are bytes from TRF7960 to MCU.

    In this moment only inventory 16 slots is not working, other commands works even if there are some unexpected behaviour from TRF 7960.

    Main problem seems to be that there are some unexpected interrupts. For example Inventory 16 slot generates IRQ 81 instead of IRQ 80 and then IRQ 1.

    I supposed TRF wait for some feedback from MCU before rising IRQ 1 after IRQ 80.

    May be I need to pay attention to some timing?

    Best regards

    Alessandro

    CONFIGURATION

    0B

    87

    00

    21

    01

    02

    06

    80

    07

    14

    09

    21

    INVENTORY 1 SLOT WORKING

    09

    21

    07

    14

    6C

    00

    3E

    8F

    91

    3D

    00

    30

    26

    01

    00

    (IRQ)

    6C

    C0 ???

    3E

    (IRQ 0x60)

    6C

    60

    3E

    7F (not need to read fifo length. It is always 9 with IRQ 0x60. Correct?)

    00

    00

    A8

    52

    1D

    15

    00

    00

    07

    E0

    00

    (IRQ 0)

    6C

    00 ???

    3E

    0C

    06

    01

    07

    00

    1D

    A8

    03

    8F

    00

    96

    00

    4C

    INVENTORY 16 SLOT NOT WORKING

    09

    21

    07

    14

    4D

    3E

    0D

    3F

    6C

    00

    3F

    8F

    91

    3D

    00

    30

    06

    01

    00

    (IRQ)

    6C

    81 ???

    81

    8F

    00

    96

    00

    4C

    READ SINGLE BLOCK WORKING

    8F

    91

    3D

    00

    30

    02

    20

    01

    (IRQ)

    6C

    C0 ???

    3E

    (IRQ 0x40)

    6C

    40

    3E

    5C

    24 (4 bytes in FIFO but I expect N-1 = 3)

    7F

    00

    01

    02

    03

    04

    00

    7E

    02

    00

    00

    (reset)

    8F

    00

    96

    00

    4C

    00

    WRITE SINGLE BLOCK (WORKING BUT TRF7960 RESET IS NEEDED AFTER)

    8F

    91

    3D

    00

    70

    42

    21

    01

    01

    02

    03

    04

    (IRQ 0xA0)

    6C

    A0

    3E

    (IRQ 0x80)

    6C

    80

    3E

    8F

    00

    8F

    00

    94

    00

    (IRQ 0x40)

    6C

    40

    3E

    5C

    00

    7F

    00

    00

    7E

    02

    00

    00

    (reset)

    8F

    00

    96

    00

    4C

    00

  • not quite sure yet why you are not getting a 0x80 for EOTX, except

    0xC0 indicates you are waiting too long to service the IRQ

    if you handle the 0x60 on RX side, then just wait for 0x40, then you will read FIFO status and find it should be 0x09 (which is indicating 10 bytes available)  - its just a risk you might miss something if you don't wait for the 0x40.

    also, i tested using 0x80 for register 0x06, did not see error, but you could just leave that at default value (0x00)

    regarding 5 bytes in FIFO when you do RSB. this is correct, you get four bytes of block data and 1 flags bytes (per ISO standard for tag response)

    regarding the 16 slots problem

    have a look at the attached. use Saleae v1.1.34 Beta software (viewer, its free, and hopefully this is the LSA you are waiting for :))

    ISO15693_16_slot_inventory_MSP430F5438A_one_tag_in_slot_0x0D.zip

  • Alessandro -

    also, please see attached logic capture with matched set of tags (see pic below) so there is a tag in each slot for 16 slot inventory

    ISO15693_16_slot_inventory_MSP430F5438A_one_tag_in_each_slot.zip

  • Hi Josh,

    sorry for the delay. I find out some timing problems I am trying to fix them.
    I think I am approaching to the correct timing. It seems I receive the correct IRQs without overlapping, the correct data in FIFO and the correct data size (N-1)

    Anyway I am still having problem with inventory 16 slot (inventory 1 slot works well). I cannot receive any IRQ after IRQ 0x80.
    I checked with data logger samples I downloaded and it seems that timing and data are the same.
    The sample you sent me seems empty. Can you please send me a correct one?
    Thank you again.

    Best regards
    Alessandro
  • try using the beta version of the Saleae GUI
    support.saleae.com/.../201589175
  • Hi Josh,

    I am back after connecting Saleae data logger.

    I made some correction to my software (mainly timing) and now I have stable results comparable to samples.

    Most commands works fine but now I have 3 remaining open issues:

    1- Inventory 16 slot returns 0x80 IRQ but I cannot reset IRQ after reading IRQ status (if I read 2 times IRQ it works fine)

    2- Write Single Block do not work using UID. I send first 16 bytes, wait 77us, send 0x3F, send the last bytes. But I have no answer from TRF.

    3- Read Multiple Blocks returns wrong values for the 3rd block. I expect  01020304 05060708 0C0B0A09 but I read 01020304 05060708 0C0C0C0B

    Any ideas?

    I have the 3 data logger capture files but I not know how to send you.

    Thank you.

    Best regards

    Alessandro

     

  • you can just zip them up and tell me which version of the GUI you are using - currently i am using the latest beta

     

  • Hi Josh,

    here are the capture files:

    Capture.zip

    I solved problem on write single block with UID (just wait for 0xA0 before sending 0x3F and bytes after 16 of the command).

    I still have some problem on:

    1 - Inventory 16 slots (I need to send a FIFO reset twice to reset IRQ from TRF... is it correct? I suspect a timing problem)

    2 - Read Multible Block (dirty values on some read blocks.... I noticed it works fine if I use I lower SPI clock rate but then other commands do not work... I do not understand how to change timing in this cases)

    Thank you.

    Best regards

    Alessandro