• State Resolved
  • Locked Locked
  • Replies 28 replies
  • Answers 1 answer
  • Subscribers 17 subscribers
  • Views 11240 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TRF7970A: CRC missing on 'Transmission With CRC' command

amello
Prodigy 130 points
Part Number: TRF7970A
Other Parts Discussed in Thread: TRF7960A

Hello,

We are using the TRF7970A to Read/Write ISO14443A Tags on our project, but we found that some of the boards are just unable to read the tags.
The REQA and the whole Anticollision Loop happens without any issue in all our boards, but the READ command that follows always fail on some of the boards.
We tried swapping the TRF7970A from a working board to a non-working one. The board that wasn't working now works fine, and the one that was working can't read the tags anymore.
We repeated this test on different boards and got the same results.
After closer inspection we found out that the TRF7970A on the defective boards are not sending CRC on the READ message.
Below is the oscilloscope capture of a working board (pink line is the IRQ PIN and blue line is the signal):
And below is the capture of a defective board (pink line is the IRQ PIN and blue line is the signal):
The READ sequence looks as follows on the software (all the boards are using the same software):
        trf7970a_write_iso_control(0x08); // ISO14443A Protocol, CRC enabled on RX
 
        // Prepare READ command
        buffer[0] = (1 << 7) | 0x0F;  // FIFO Reset (Direct command)
        buffer[1] = (1 << 7) | 0x11;  // Transmission with CRC (Direct command)
        buffer[2] = (1 << 5) | 0x1D;  // Continuous write starting at address 0x1D
 
        // TX Length setup
        buffer[3] = 0x00;
        buffer[4] = 0x20;
        buffer[5] = 0x30;  // Type 2 tag READ command
        buffer[6] = block;
 
        trf7970a_write_raw_data(buffer, 7);  // Send buffer data to TRF
Any idea why this is happening?
Regards,
André
  • 0
    TI__Guru*** 128205 points
    Hello Andre,

    That the issue follows the chip is a bit concerning if the same software is used on both boards. I would like to ensure the device is being configured and handled correctly first. We have seen variance where if not configured/handled correctly some devices end up in a 'bad state' where it doesn't behave as expected. Therefore I'd like to verify this isn't happening first.

    Is the software being used TI example code? Is the processor an MSP430?

    From a software standpoint, how is the initial device configuration being handled?

    Next, are there any attempts to re-configure the device and re-issue the 'failed' READ command? If so, what steps are taken to achieve this?

    Lastly, in general when sending and receiving data whether it is for the REQA, through the Anticollision loop, or with the READ command, is the FIFO being reset at the end of every transmissions and reception of data?
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    Thanks for your reply. Answering your questions:

    Is the software being used TI example code? Is the processor an MSP430?

     

    The software is based on the example code, but it's not exactly the same as you will see in the samples below.

    We are using a arm cortex-m3 from NXP as the processor and SPI with SS to control the TRF.

    From a software standpoint, how is the initial device configuration being handled?

     

    Sometimes the TRF would not take default values during initialization (as stated on the Firmware Design Hints), so the init code is as follows:

            buffer[0] = 0x83; // RESET command
            buffer[1] = 0x80; // IDLE command

            trf7970a_write_raw_data(buffer, 2);

            delay_ms(100); // Wait for TRF7970A initialization

            // Init registers
            buffer[0] = 0x20; // Continuous write from register 0x00
            buffer[1] = 0x21; // Reg 0x00: RF on and 5V mode
            buffer[2] = 0x88; // Reg 0x01: ISO14443A without CRC

            // Default values for ISO14443A protocol
            buffer[3] = 0x00; // Reg 0x02
            buffer[4] = 0x00; // Reg 0x03
            buffer[5] = 0xC1; // Reg 0x04
            buffer[6] = 0xBB; // Reg 0x05
            buffer[7] = 0x20; // Reg 0x06
            buffer[8] = 0x0E; // Reg 0x07
            buffer[9] = 0x07; // Reg 0x08
            buffer[10] = 0x21; // Reg 0x09
            buffer[11] = 0x20; // Reg 0x0A
            buffer[12] = 0x87; // Reg 0x0B

            trf7970a_write_raw_data(buffer, 13);

            // Init NFC Target Level reg to avoid reading holes
            trf7970a_write_single_reg(TRF_NFC_TARGET_LEVEL, 0x00);

     

    The values of the registers are read before moving on to make sure they are exactly as I wrote them.

    Next, are there any attempts to re-configure the device and re-issue the 'failed' READ command? If so, what steps are taken to achieve this?

    Currently, everytime I write to the ISO Control Register the device is 'reconfigured'. When I need to toggle between ISO14443A with and without CRC on RX I use the trf7970a_write_iso_control(uint8_t iso_control) function. This function sets the default values of the registers again:

            buffer[0] = 0x20; // Continuous write from register 0x00
            buffer[1] = 0x21; // Reg 0x00: RF on and 5V mode
            buffer[2] = iso_control; // Reg 0x01: ISO14443A with or without CRC

            // Default values for ISO14443A protocol
            buffer[3] = 0x00; // Reg 0x02
            buffer[4] = 0x00; // Reg 0x03
            buffer[5] = 0xC1; // Reg 0x04
            buffer[6] = 0xBB; // Reg 0x05
            buffer[7] = 0x20; // Reg 0x06
            buffer[8] = 0x0E; // Reg 0x07
            buffer[9] = 0x07; // Reg 0x08
            buffer[10] = 0x21; // Reg 0x09
            buffer[11] = 0x20; // Reg 0x0A
            buffer[12] = 0x87; // Reg 0x0B.

            // Send buffer data
            trf7970a_write_raw_data(buffer, sizeof(buffer));

     

    The NFC tag reading procedure is called inside a loop that tries to poll for tags constantly. The Reading procedure always follows these steps when it is called:

    - Turn on RF and wait 6 ms to power tag up.
    - Send REQA.
    - Anticollision Loop.
    - READ block 4.
    - READ block 8.
    - READ block 12.
    - Turn RF off.

    If any of these steps fail, the procedure is interrupted, turns the RF off and returns a fail code. Thats why there is no READ block 8 and READ block 12 on the defective board's oscilloscope capture.
    This procedure fails everytime it is called on the defective boards and suceeds everytime on the working ones.

    Lastly, in general when sending and receiving data whether it is for the REQA, through the Anticollision loop, or with the READ command, is the FIFO being reset at the end of every transmissions and reception of data?

    Yes, it is. I also reset the FIFO before I send any of these commands (REQA, Select, READ) following the same pattern of the code on my first post (buffer[0] = (1 << 7) | 0x0F; // FIFO Reset (Direct command))

    Best regards,

    André

  • 0 in reply to amello
    TI__Guru*** 128205 points

    Hello Andre,

    Overall the software process looks pretty solid. There are a couple things I would like you to try and if either of these suggestions do not resolve the issue then I think hardware will be the next area to investigate.

    1) The TRF7970A actually doesn't have an issue with setting the registers to correct values (the Firmware Design Hints should specify that applies for the TRF7960A, I will see that is fixed), so just write to the following registers and leave the others alone and let the ISO Control automatic settings handle that:

    • Chip Status Control
    • ISO Control
    • Modulator and SYS_CLK Control
    • RX Special Setting (Optional)
    • Regulator and I/O Control - Also recommend trying setting 0x00 or 0x01 for this rather than using 0x87

    2) Each time you configure the ISO Control Register, start by doing a Soft Init and Idle (0x83, 0x80) sequence and then write the registers as needed. This ensures the device starts in a clean known state before getting re-configured for the current protocol. Also remember to clear Register 0x18 each time you do a Soft Init. Edit: per below comments, this method does not work for reconfiguring the TRF79xx ISO14443A settings between anticollision and Read.

  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    I made the changes suggested in 1 on both the init and the write_iso_control function. The code looks cleaner now but the behavior is the same.

    There is a problem with suggestion 2. Doing the Soft Init and Idle sequence turns off the RF signal for about 60us everytime I call the write_iso_control function and it seems to be enough to turn off the Tag.

    When the REQA command is sent right after the write_iso_control there is no response from the Tag. If I put a 6ms delay before returning from write_iso_control the tag responds the REQA, but do not respond the anticollision, probably because it rebooted to its initial state.

    Best Regards,

    André

  • 0 in reply to amello
    TI__Guru*** 128205 points
    Hello Andre,

    Sorry about point 2, the behavior you described makes sense. I was thinking along the lines of changing protocols, but yes in our example code the only step taken to change the registers for ISO14443A Read's is to Write to the ISO Control register. No other configurations are made. I apologize for the misleading comment on that one.

    I would like to review your schematic next. Feel free to send it offline from the public E2E forums if you wish.
  • 0 in reply to Ralph Jacobi
    TI__Guru*** 128205 points

    Hello Andre,

    Thanks, I received your schematic and have reviewed it.

    There is one point of large concern for me is that you have a +5V signal tied straight to the EN line. The datasheet specifications for EN is that it's max voltage is determined by VDD_IO which is tied to VDD_X and will be far below +5V. This connection could result in damage to the IC and this could explain the behavior you are seeing. For reference, the I/O tolerances are in Section 5.2 Recommended Operating Conditions on Page 9.

    You should modify a board (or multiple) to either tie EN to an MCU GPIO or some 3.3V source (VDD_X will be 3.4V in your configuration). Then test with a suitable sample of devices to see if this issue comes up again or not. You will need to use new devices as any currently failing devices now should be suspected of having the potential to have been damaged.

    One more issue I noticed is that on the TRF7970A 50 ohm match, there is a component with the wrong value used. C319 should be 680pF, not 1.2nF. This won't cause an issue like stopping the device from transmitting the CRC, but it could affect RF performance in general as now the impedance for the antenna matching would not be at 50ohms. This is an important fix in the grand scheme of your application even if it isn't directly related to the current issue.

  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    Thanks for your reply,

    We made the corrections on the boards and bought new transceivers to test. We will test them as soon as they arrive and report back here with news.

    One thing that I noticed is that the datasheet is not very clear with the maximum value of the EN pin. The table you mentioned don't actually specifies a maximum value for the EN pin. It specifies a maximum value for logic low threshold (0.2 x VDD_I/O) and a minimum value for the logic high threshold (0.8 x VDD_I/O). Even though it uses the VDD_I/O as reference, I couldn't find anything about maximum value.

    The EN2 pin is in the same table and the datasheet mentions it can be directly connected to VIN. The EN2 pin affects the VDD_X output, so it makes sense not to tie them together, but this can be a bit misleading.

    Best Regards,

    André

  • 0 in reply to amello
    TI__Guru*** 128205 points

    Hello Andre,

    I am going to check with design about if there is a max level for EN based on VDD_IO. In all previous applications I've worked with, I haven't seen EN tied to +5V but I do agree that the maximum value isn't stated and it is unclear if that could have a negative effect.

  • 0 in reply to Ralph Jacobi
    TI__Guru*** 128205 points
    Hello Andre,

    Your point is valid and there isn't a maximum specification related to VDD_IO for those pins. They just can't exceed the input voltage for Recommended Operating Conditions, so for the 5V system you can have EN/EN2 tied to 5V. I apologize for the misleading information from my mistake.

    I've reached out offline about the next step which is to ship me a couple samples of these failing devices. As mentioned above, I don't believe the matching network component is causing this so I would like to investigate with 2 or more devices and see if the CRC is not transmitted on our own test board setup.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points
    Hello Ralph,

    We tested 3 new TRFs on a 'corrected' board, one of them is not sending CRC on the READ command.

    We are sending you 3 defective TRFs (including this recently purchased one), but it may take a while for them to get there due to paperwork.

    Best Regards,

    André
  • 0 in reply to amello
    TI__Guru*** 128205 points
    Hi Andre,

    Okay, sounds good.

    Something else just came to mind, what frequency is your SPI clock running at?
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    It is configured to 2 MHz, but I just measured it with the oscilloscope and it is running close to 1.8 MHz.

    The 'DATA_CLK time high or low' is lower than the MIN value specified at '5.6 Switching Characteristics'.

    I'll have a look at that to make sure it is within the specified range.

    Best Regards,

    André

  • 0 in reply to amello
    Prodigy 10 points
    Hello Ralph

    I'm also a member of this development team.
    Yesterday I worked on a FW workaround to this problem. I changed the CRC handling from the TRF to the FW, performing the CRC calculation and checking it into the FW.
    With this modified FW, I tested one board that presented the CRC problem and this board was working now, reading and writing the full tag data.
    Andre will still perform tests with this FW in some more samples.
    Anyway, I believe it is an additional information to reach the root cause of the problem and solve it definitively.

    Best regards
    Marcelo
  • 0 in reply to Marcelo Belao
    TI__Guru*** 128205 points
    Hello Marcelo,

    That makes a lot of sense, and I certainly expected if the CRC was issued like that, the tag would reply. Good to know it's been tested. There is a chance that SPI issue could be causing a problem as we have observed going below the SPI frequency can cause unusual behavior and I'd characterize this as unusual behavior. Let me know if anything improves when that is handled.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    I raised the SPI clock to 2.05 MHz and I found another problem. The MISO line sometimes just hangs at high level and the communication fails.

    The TRF is able to read the tag sometimes (even the ones that had the CRC problem) but the MISO error is happening very often in all the boards, even the working ones.

    I tried raising the SPI to around 3 MHz and it just got out of control. Then I lowered it to around 1 MHz and it was working just as before (the ones that worked previously kept working and the ones that didn't send CRC kept not sending it).

    Here are a some oscilloscope captures from a working board (one with no CRC issue) showing the spi lines:

    Yellow line is clock, pink line is MOSI and blue line is MISO.

    Best Regards,

    André

  • 0 in reply to amello
    TI__Guru*** 128205 points

    Hello Andre,

    That doesn't sound right. I haven't seen that sort of behavior with our MSP430 devices. For example, our main NFC stack uses 4MHz and it runs great like that, no issues at all. It's been tested like that on a lot of devices over time too.

    I'm going to attach a screen capture from my Logic State Analyzer showing the full communication cycle from setup through reading multiple blocks of data from a Type 2 tag. See if this helps at all with your debugging: Type2_Read_Blocks.logicdata

    You will need to download the Saleae Logic program from: https://www.saleae.com/downloads

    I used version 1.2.2 to take the capture but the newer versions will open it just fine.

  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    2 differences between the SPI trace you sent and our firmware caught my attention:

    - There is no dummy read on the IRQ Status Register to clear it. Since this register is not read 2 times in a row I think it makes sense.

    - The ISO Control Register is only configured once in 'ISO14443A with no CRC on RX' mode. The CRC bytes are present in the trace when the FIFO is read.

    Is the CRC verified on FW?

    I changed the software to not reconfigure the ISO Control Register after initialization, just like the trace, and now all the boards I tested work without CRC issue on transmission. We still need Marcelo's workaround to calculate the CRC on the RX side though.

    Best Regards,

    André

  • 0 in reply to amello
    TI__Guru*** 128205 points

    Hi Andre,

    Actually I had forgotten that was the setup for the firmware which actually in hindsight I need to further adjust. Anyways I went ahead and added in the write register to configure for 14443A with CRC check on RX (which is 0x08) before reading blocks of data.

    See the new attached capture which shows this doesn't change the results: Type2_Read_Blocks_New.logicdata

  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    We debugged the SPI problem. It was caused by interruptions happening during SPI FIFO writes. This condition could toggle the Slave Select pin OFF and ON again for a very short time between bytes at higher speeds. It is fixed now.

    We are running the SPI at 2.5 MHz but the CRC problem is unchanged (Also tested with SPI running at 5 MHz).

    Best regards,

    André

  • 0 in reply to amello
    TI__Guru*** 128205 points
    Hello Andre,

    Would it be possible to provide a comprehensive logic capture similar to what I shared across the SPI communication process for both a working and a failing board? I would like to compare the sequence of commands and also the states of the MISO/MOSI lines to what is working on my test board system with the devices I had received since it seems the issue is rooted somewhere in the software based on my test results.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    Sorry for the (very) late reply. I was just able to come back to this issue.

    I'm sending you the logic captures of a working board and a defective one.

    Best regards,

    André

    captures.rar (the site wont let me insert .logicdata files, how you did it?)

  • 0 in reply to amello
    TI__Guru*** 128205 points
    Hello Andre,

    My first thought from looking at your captures is that you should not reconfigure the registers between every command - that only needs to be done once after software resetting the device via SOFT INIT. Also the delay between the SOFT INIT+IDLE commands and registers configs can be 1ms, not 100ms (just to save you time).

    After you configure the registers once, the only time you need to do any configs is when toggling RX with CRC on and off in ISO Control.

    Please see if that makes any difference... I'm not really sure one way or another if it would because this is the first time I've seen a situation where all those register settings are made between every single command.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    Thanks for the input.

    I modified the software with the suggestions. It is cleaner now but the problem persists.

    I'm sending the new logic captures.

    Best regards,

    André

    captures2.rar

  • 0 in reply to amello
    TI__Guru*** 128205 points
    Hello Andre,

    Thanks for the latest capture. Almost everything looks right to me though one other point I noticed which I am not sure how much of an impact it will have is that you send the Stop Decoders command after every read. This is a different step from my own process, but in theory this shouldn't be an issue, as you can see in the working cases the device behaves as expected. I'd like to see if you remove that "Stop Decoders" direct command being issued from SUCCESSFUL receptions (i.e. RX without any errors like CRC/Collision) if the read block works then.

    If that does fix the issue, I can investigate further on my end via the chips I still have from you.

    I had the time to look through our dialogue from the prior months, from a hardware standpoint, have you tried swapping the 'failing' chip to a board which is working? Does the issue follow the device? I didn't see a comment that this was tried yet. Would be a good test.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points

    Hello Ralph,

    Good news! It did work! I could only test it with one defective sample for now, but I'll try the rest as soon as I can.

    I'm sending the latest captures comparing the behavior with and without the 'stop decoders' command on successful reads, both from the same board which was defective.

    We did swap the chips between boards. I was only able to track the issue down to the chip because of this test (since it was a brand new prototype with other issues and all). I tried reporting this on the very first post.

    When I say 'defective board' I actually mean 'board with failing chip'. Sorry for the misleading choice of words.

    I kept the 'failing' chips separated from the rest and the behavior is consistent no matter the board they are tested on.

    We even bought new chips to make sure it wasn't a 'bad lot' or something. The new ones presented the same behavior: some worked and some failed. Not sure about the exact numbers right now, but failure rate was very high (close to half tested chips). I think one of the chips we sent you came from the 'new batch'.

    Best regards,

    André

    captures3.rar

  • 0 in reply to amello
    TI__Guru*** 128205 points
    Hello Andre,

    Not sure how I missed the chip swap explanation staring me right in the face, sorry for re-raising the question, fully understood.

    Glad to hear the removal of the Stop Decoder command seems to address this. Please do let me know if this resolves it across other boards. If not, I have the devices you sent me still and can test what impact that command on the success vs failure of the read block command when using a TI MCU+Firmware on our test setup instead.

    This is the first time I've seen that process done, so I will definitely keep this behavior in mind for the future if that is confirmed to solve the issue across all your failing boards.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points
    Hello Ralph,

    The team was able to test the fix on different boards that were failing before and all of them worked.

    Thanks for all your help.

    Best regards,

    André
  • 0 in reply to amello
    TI__Guru*** 128205 points

    Hi Andre,

    That's great!! Sorry it look so long to track it down. Thanks for confirming the solution, gives me something else to keep in mind moving forward.