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.

MSP-EXP430G2ET: Issue in using with DLP7970ABP in SDM mode for Mifare Classic Authentication

Part Number: MSP-EXP430G2ET
Other Parts Discussed in Thread: MSP430F2370, TRF7970A, DLP-7970ABP, MSP430G2553

Hello All,

I am using the Hardware combination MSP-EXP430G2ET + DLP7970ABP (V4.7) for Mifare classic authentication process.

I used the sample code SLOC297C. With this the Anti-collision process is executed successfully and I can read the UID of the Mifare classic 4K tag.

To this sample code I ported the SDM code from SLOA214 for adding the Authentication functionality. But the Authentication process is not successful. The code is blocked indefinitely in the "Mifare_DM1_Recieve()" while waiting for the (SDM_BITCLK rising edge) response from the tag. While debugging I suspected that the data is not transmitted properly and hence there is no response from the Tag.

Therefore, I enabled the interrupt for the "SDM_BITCLK" to check the Mifare_SDM_Transmit() function. After enabling the interrupt, I could see continuous interrupts in the line and it is not reliable. I also verified that this is not due to porting but it happens with the SLOC297C code itself. But still (when the interrupt is disabled) the anti-collision process is successful but the authentication process blocked. I hope the reason for this is, only in authentication process (SDM mode) the P1.3(SDM_BITCLK) is used but not during anti-collision process. I observe that this interrupt starts as soon as the TRF79xxA_turnRfOn() function is executed without writing other register settings.

Please help me to solve my issue. Hope I made the necessary changes. Let me know if I am missing something.

I didn't modify the clock configuration in SLOC297C. Not sure whether this issue is related to clock settings. Also, by default, R5 and R7 is unmounted in MSP-EXP430G2ET. Hope there is no need to use the external crystal.

Changes made to MSP-EXP430G2ET are,

  1.  Enabled HW UART in J101,
  2. Opened J7,
  3. Opened J6,
  4. Removed R6.(Removed R6 only after facing this issue, thinking pull up on switch button is causing the above problem. But same behavior with and without R6).

Please let me know if any other HW change is required.

Thanks and Regards,

Skumar

  • Hi,

    Can you post the combined code? It will much easy for me to look into.

    Eason

  • Hi Eason,

    Thanks for your response. Please find the attached code. I have ported the SDM implementation from SLOA214 to SLOC297C. But I confirmed that the issue is not related to porting. The same behavior occurs in SLOC297C itself. I am not sure what is the problem.

    Please help me to complete the Mifare classic Authentication process.

    Please let me know for any clarification.

    TRF7970ABP_RFID_Reader_Demo.rar

     

    Thanks and Regards,

    Sunil

  • Hi Eason,

    Hope you are doing good. Do you have any update? Are you able to reproduce the issue?

    Thanks and Regards,

    Sunil

  • Hi Sunil,

    SLOA214 firmware is base on TRF7970A EVM, and the MCU on this hardware board is MSP430F2370, SDM_BITCLK is P4.5, as follow:

    I checked the following program you modified and found that you changed this port to P1.3, however this I / O port is not connected to the MSP430G2ET and TRF7970ABP hardware connections.

    Thus check the hardware connection of these two boards may be very helpful for your debug.

    Best Regards

    Johnson

  • Hi Johnson,

    Thanks for your response.

    I think it is connected in the newer version of booster pack DLP-7970ABP V4.5 and it supports SDM mode. Please refer the below image grouped from various documents. Please let me know if I am wrong.

    Thanks and Regards,

    Sunil

  • Hi All,

    Is there any update from anybody?  Please help me.

    Thanks and Regards,

    Skumar

  • Hi Skumar,

    Sorry, you question is beyond our knowledge and has a more relationship with NFC. I will try to find a suitable e2e thread catalog to re-assign your question. 

    Eason

  • Hi Eason,

    Thanks for your response. I will be waiting.

    Thanks and Regards,

    Sunil

  • Hi Sunil,

    to help you further with the TRF7970A Direct Modes it would be very helpful to see some timing diagrams. Do you have access to a logic analyzer or oscilloscope to trace the relevant signals and send us a screenshot.

    From what you have written the connection between the TRF Booster Pack V4.5 and Launchpad seems to be ok.

    Best regards,

    Helfried

     

  • Hi Helfried,

    Thanks for your response.

    I will have some limited access in few days. Please let me know the signals that you want to trace. 

    Thanks and Regards,

    Sunil

  • HI Sunil,

    I have put your code to my system and found out that after the Anti-collision sequence nothing more is transmitted, which explains why you do not receive any data from the card.

    You have made a lot of modifications to the Mifare_SDM_Transmit routine and added an ISR for the Port 1. After restoring the Mifare_SDM_Transmit routine back to the original code and removal the Port 1 ISR the TRF7970A is transmitting the data 60 00 F5 7B  and the card sends back some data. Please see the attached screenshot. I am not familiar with the Mifare Authentication so please check if this is what  you want to see.

    Best regards,

    Helfried 

  • Hi Helfried,

    Thanks a lot for your efforts. 

    I can say that the data 60 00 F5 7B transmitted by TRF7970A is correct. But after that we cannot say the expected data because of the Mifare Authentication protocol. But the expected data bytes from the card is 4 bytes as in your case. After that TRF7970A will transmit 8 bytes of data and the card will again respond with the 4 bytes data. After this the Mifare Authentication process is completed and should pass. Is it possible for you to check this?

    Can you please share your working code?

    Which hardware are you using? (DLP7970ABP + MSP-EXP430G2ET) or different?

    Note,

    I have not made much changes to the original code. I just included some debug messages and ISR for debugging. I shared the same code with you to get the idea of my debugging.

    The one change I made is that I cleared the g_ui8TimeoutFlag at the end of Mifare_SDM_Enter(). I thought this flag should be cleared since if this is not cleared, the while loop in Mifare_SDM_Transmit() will release immediately without waiting for the SDM_BITCLK. 

    while(SDM_BITCLK && (!IRQ) && (!g_ui8TimeoutFlag));           // wait for Falling edge

    Thanks and Regards,

    Skumar

  • Hi Sunil,

    the hardware is the same that you are using. TRF7970ABP V4.5 with EXP430G2 Launchpad (MSP430G2553).

    Here is my modified code:

    E2E_Mifare.zip

    Best regards,

    Helfried

  • Hi Helfried,

    Thanks for your response. I tried your code and the Mifare authentication process is failing. Hope its failing on your side too. Please confirm to make sure there is no hardware issue on my side.

    I got this same behavior when I first ported my code, Mifare authentication was failing. Only after this I started debugging the code. I am not sure what is the issue or whether any adjustment in the clock is required.

    The time period of SDM_Bitclk seems to be 10us. I am not sure whether MSP430G2 is configured fast enough to respond correctly.

    Please help me.

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    Helfried raised this question with me as I have more experience with this example.

    The MIFARE Classic procedure with SDM is extremely timing sensitive in order to both trigger Special Direct Mode to function correctly as well as transmit and receive data using BitClk.

    The time period of SDM_Bitclk needs to be 9.44 us or very, very close to that.

    The MSP430G2 should run at 16 MHz. That is the speed the MSP430F2370 was running. It is recommended to use the same speed as if you are using an MSP430 at the same clock speed than you do not need to mess with any timings and can keep the routine untouched.

    At this time we do not support any modifications made to the SDM process. If you need to adjust timings, then that it will be up to you to read the app note and understand what you are doing. We are not in position to debug issues with custom timing adjustments.

  • Hi Helfried and Ralph Jacobi,

    Thanks a lot for your response.

    I don't need any timing adjustments or I don't need any modifications in the SDM process. All I want is that the given SDM sample SLOA214 to work in my (DLP7970ABP + MSP-EXP430G2ET) setup.

    You are saying that MSP430F2370 was running at 16MHz, but in the SDM sample source code I can see that BCSCTL1 = CALBC1_8MHZ; and DCOCTL  = CALDCO_8MHZ; By this I understand that the MSP430F2370 runs with internal DCO at 8MHz. Please let me know if I am wrong.

    If everything should work when MSP430G2 runs at 16MHz, Can you please check the same with the (DLP7970ABP + MSP-EXP430G2ET) Hardware and Code that you already shared with me and confirm? I just want to make sure that there are no problems with my hardware or its settings.

    Once again thanking you.

    Thanks and Regards,

    SKumar

  • Hello Sunil,

    You mentioned before:

    Sunil Kumar Mohan kumar said:

    The one change I made is that I cleared the g_ui8TimeoutFlag at the end of Mifare_SDM_Enter(). I thought this flag should be cleared since if this is not cleared, the while loop in Mifare_SDM_Transmit() will release immediately without waiting for the SDM_BITCLK. 

    while(SDM_BITCLK && (!IRQ) && (!g_ui8TimeoutFlag));           // wait for Falling edge

    That is a change to the setup process that is proven.

    You are right about Clock Speed, sorry that was my bad memory - I haven't touched the code in a while. It is 8MHz, so it'd be better to run the G2553 at 8 MHz. Bumping from 8 MHz to 16 MHz would require adjustments to the timing.

    To check hardware issues, get a logic state analyzer and monitor the signals yourself and then compare to the app note to make sure everything is output correct, that is not something we have the bandwidth to do on your behalf.

  • Hi Ralph Jacobi and Helfried,

    Thanks for your response.

    I made the mentioned change only because the original code was not working and it is not intentional. 

    The Mifare authentication is failing with the original proven setup process and also with the code given by Helfried. In both the code, G2553 runs at 8MHz only.

    So I hope the code doesn't work even for you too.  Please help me make the Mifare authentication successful.

    Please confirm successful Mifare Authentication in the code shared by you on your (DLP-7970ABP + MSP-EXP430G2ET) setup. 

    Thanks and Regards,

    Sunil

  • Hi Sunil,

    I spend a little time looking in your code again. Because this code for the Direct Modes is very timing critical any debug output especially via the UART will destroy the correct timing I removed all debug output in this part.

    The most critical routine is the Direct Mode 1 receive which I could not get to work with 8MHz clock. After a modification to speed up the DM1 receive and setting the clock speed to 12MHz the Mifare Authentication seems to work successful. If the change of the clock speed has other side effect must be verified at your side.

    Please try the attached code.

    I am sorry but further support for code debugging is not possible from my side.

    Best regards,

    Helfried

    E2E_Mifare2.zip

  • Hi Helfried,

    Thanks for your time and the sample code. I will investigate on my side and let you know.

    Thanks and Regards,

    Sunil

  • Hi Ralph Jacobi and Helfried,

    I tried the code you gave and there is no improvement on my side. I get the same behavior as before. I captured and analyzed the signals with a help of logic analyzer. Below is the summary and I have also attached the waveforms for your reference.  

    The waveforms of  SDM_Config, SDM_Enter, SDM_Transmit, SDM_Exit and DM1_Enter are all same as mentioned in the Application note SLOA214-Feb2015. But still I didn't get any response from TRF7970A. i.e there is no Bit_Clk or no MISO data in the DM1_Receive. The DM1_Receive breaks after the 40ms timeout. I can see that the waveform of all the steps before DM1_Receive matches with the SLOA214 but there is no response from TRF7970A in DM1_receive. I am not sure what is going wrong here. 

    Please look at the waveform and let me know if I am missing anything. Please let me know what could be wrong and causing the issue, so that I will debug on my side. 

    I kindly request your assistance here to solve this issue.  This is critical. Thanking you.

    Mifare Authentication Signal Capture.rar

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    because we are using the same HW setup and the code is working on my side I have to assume that the problem is on the tag side. Can you confirm that your card is a Mifare Classic and is working with authentication?

    This is already beyond the support we can offer and so I am not able to spend more time in this case.

    Please try to check with an oscilloscope if the card is really answering to the request.

    Best regards,

    Helfried 

  • Hi Helfried,

    Thanks for your response.

    I checked with Mifare Classic 4K cards from two different vendors and got the same response. Can you please tell me how to confirm whether the card is working with Authentication? Can you please share the details of the card that you are using so that I will try to use the same.

    Did you checked my waveforms? Do you feel that something need to be adjusted? Or do you find any issue in the signals based on your experience?

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    I use a Mifare Classic 1K, so your card is ok.

    I put here the data capture of my Logicanalyzer as reference for you. You can check if there is a difference to your capture.

    Mifare_Autentication.zip

    Also a screenshot of a my spy:

    Best regards,

    Helfried

  • For added help, here is another set of LSA capture from the app note example + hardware:

    MIFARE_Classic_SDM_Auth.logicdata

    You can view with the Saleae Logic software.

  • Hi Ralph Jacobi and Helfried,

    Thanks for your responses.

    I will debug on my side and come back to you.

    Thanks and Regards,

    Sunil

  • Hi Ralph Jacobi and Helfried,

    I debugged on my side but couldn't find a solution. I used the same code as you gave(which you confirmed it works on DLP7970ABP+MSP430EXPG2ET platform) and the same setup but couldn't get the response back from Mifare Classic tags.

    1. I tried with 4K and 1K tags and get the same behavior. So I don't think that the issue is related to the Mifare Classic tag. 
    2. I also checked my waveforms with the application note and as well as with the one that you gave and verified that everything matched till DM1_Enter.
    3. My doubt next shifts to the Hardware, I am using the DLP-7970ABP v4.7 and MSP-EXP430G2ET Rev.1.0 Sep2017 boards operating at 3V Vcc.. Please let me know the version of boards that you use and the operating voltage. Also please recollect and check and let me know whether you have made any changes to the hardware setup.

    I further debugged and probed the RF signal at the 19th pin of the 22pin DLP-RFID2 module (as I could not find RX1_AM and TX_OUT pins of TRF7970A separately in DLP7970ABP). I can see that the RF signal suddenly goes OFF during the DM1_Receive. I have attached the images for your reference. I hope the RF signal should be present during both Transmit and Receive functions. I couldn't understand the reason for this. Please let me know if you had faced this issue already or any idea about this. Please let me know how to proceed.

    Please help me and provide your guidance to solve this issue. Thanking you.

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    Helfried is out of office until early next week and as he was the one who had tested this setup with the code provided, we will need his comments on this topic. Sorry for the delay on our end.

  • Hi Ralph Jacobi,

    Thanks for the update. Let us wait. 

    Meanwhile, I just saw a E2E forum with a similar problem related to authentication already solved. In that "Manuel Lopez" has reported that he didn't get any response from tag for "Crypto1 Authentication Step 1" and the solution given for that was a code specific to TRF7970A. Though it is related to DM0 mode, I wonder whether me too need to change my code specific to TRF7970A?? Please find the link of that E2E forum below for your reference. Can you please look into it and let me know if you get some clue?

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    All our MIFARE Classic examples are for the TRF7970A.

    The code referenced there was an old Direct Mode 0 code that was hacked together to work and isn't compatible with our EVMs nowadays anyways. I've never even tested or used it, and I've been working with the device in 2014.

  • Hi Ralph Jacobi,

    Thanks for your response.

    While we wait, please let me know if I can try something to debug this issue. This is critical now as I am already running out of time for delivery.

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    Unfortunately I am not sure what else to suggest if you have compared your timings to the ones I had posted before from the logic capture.

    I did not develop that example and the developer is no longer available for us to check with regarding how to debug more.

  • Hi Helfried,

    Are you back to Office? Can you please help me?

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    Unfortunately Helfried will be out for longer than anticipated.

    I tried getting his provided example to work on my hardware in order to attempt to help in the meantime, but I have older hardware which I believe is not compatible with the example he provided...

  • 6557.TRF7970A SDM Sample sloa214.rar

    Hi Ralph Jacobi,

    Thanks for your response.

    I need to make my debugging process more clear. So that we can work on clear plan towards finding a solution.

    1. Test with the Helfried's binary which he confirmed that it is working with (DLP7970ABP v4.5 + MSP-EXP430G2ET ). With this I can narrow down on the cause of the issue. I request Helfried or you (if possible) to share it. I will wait for this.

    2. Reason for RF output OFF after DM1_Enter. I may be wrong, but I suspect that I didn't get the response from the Mifare tag since the TRF7970A is not generating the RF carrier output (due to some issue) after entering DM1_Enter. I am not sure about the reasons but please check with your teams on what all could be possible reasons for this with their experience.(I have already shared the images above for your reference). I hope the issue is not on the Mifare tag access as I hope that I should get at least some response (pass or fail) from the tag for the command "Authentication with Key A" (0x60, 0x00) irrespective of the valid KeyA. Please let me know if my understanding is wrong anywhere.

    3. I get same issue with the SLOA214 sample code. I ported the SLOA214 sample code for (DLP7970ABP + MSP430G2ET) setup, without any changes to the actual code related to Functionality and timing. I get the same issue. I have attached my ported source code for your reference. I have also attached my Saleae capture. I kindly request you to have a look at it and give me clue/suggestions.  Let me know if you suspect any timing issues, I will check more into that.

    Please help me.

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    Sunil Kumar Mohan kumar said:
    1. Test with the Helfried's binary which he confirmed that it is working with (DLP7970ABP v4.5 + MSP-EXP430G2ET ). With this I can narrow down on the cause of the issue. I request Helfried or you (if possible) to share it. I will wait for this.

    Helfried shared this code here: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/868884/3234229#3234229

    Sunil Kumar Mohan kumar said:
    2. Reason for RF output OFF after DM1_Enter. I may be wrong, but I suspect that I didn't get the response from the Mifare tag since the TRF7970A is not generating the RF carrier output (due to some issue) after entering DM1_Enter. I am not sure about the reasons but please check with your teams on what all could be possible reasons for this with their experience.(I have already shared the images above for your reference). I hope the issue is not on the Mifare tag access as I hope that I should get at least some response (pass or fail) from the tag for the command "Authentication with Key A" (0x60, 0x00) irrespective of the valid KeyA. Please let me know if my understanding is wrong anywhere.

    The developers for this example are not with the team anymore and I don't have the in-depth knowledge of how SDM works to comment on this. If the carrier output is not turning on, then to me that indicates that the timing of switching to receive mode in DM1 is off. I recall the engineer stressed heavily that the timings are extremely critical for these transitions. We provided a working capture with timings so you can compare if you are taking too long or entering too quickly for that specific step.

    We are not in position to do detailed code or timing analysis for a ported version of this example at this time. I am not sure what has tied you up on this, but many other customers have been able to get this working with the level of guidance we have been able to offer even though they use very different MCUs or system setups (faster clocks etc. which required adjusting delays).

  • Hi Ralph Jacobi,

    Thanks for your response.

    I already have the Helfried's source code but it does not work for me. That is why I asked his binary to identify if there are any build issues on my side. I already tried loading the binary available in the source code folder, but it is not loading in my HW. So please share his binary.

    Regarding the SLOA214 porting code, I haven't modified any part of the code, I just changed the mcu.h  file. So I am sure loading and checking it will not take more than 10 mins for you.

    You are talking about the timing issue, but I checked all the timings compared to the SLOA214 application note and already shared the same to you. If you suspect timing issue then checking my waveforms also will not take much time for you. I am not sure where I am going wrong or the problem is with the HW and SW.

    Thanks and Regards,

    Sunil

  • Hi,

    Is there any update? I am still waiting.

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    still unclear what is the difference between my setup which is working and yours which troubles you.

    I will give you detailed information what I am using so that you can compare if there are any differences between our setups.

    The fact that you can not download the binary that is include in my project files makes me wonder.

    Here are pictures of my boards

    Screenshot of the used Compiler:

    Finally the CCS Project.

    E2E_Mifare_2020_03_03.zip

    The Card I used for the test is a Mifare Classic 1K.

    Hope that helps to verify our setups.

    Best regards,

    Helfried 

  • Hi Helfried,

    Thanks for your response. Hope you are doing good.

    I find some difference between your setup and mine. I have the MSP-EXP430G2ET Rev 1.0 dev kit and yours is MSP-EXP430G2. I have  DVP7970ABP v4.7. Please refer the attached image. I suspect this could be a reason for not working on my side. Please let me know.

    This time, I can load the binary in debug folder in this project, but still the same behavior. Mifare authentication is failing. Please refer the debug print below.

    I hope this will make you understand what is happening on my side.

    MSP-EXP430G2ET:

    DLP7970ABP V4.7

    Project Property:

    Debug Msg:

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    With Helfried's V4.5 hardware I am also not able to pass auth which is very strange. Unfortunately due to COVID-19, I am currently lacking some pieces to try and debug the issue fully. TBD on when I will be able to get what I need on my end. Though I am working w/ Helfried on some debug activities, if any of those bare results, I'll let you know immediately.

  • Hi Ralph Jacobi,

    Thanks for your efforts. I hope now you can understand the issue on my side. 

    From your statement, my understanding is that you tested with Helfried's binary/source code. Please confirm.

    Which LaunchPad did you used with V4.5 DLP7970ABP? I am having MSP-EXP430G2ET Rev1.0. Helfried is having MSP-EXP430G2 Rev1.5.

    I suspect whether the difference in the Launchpad is causing some issue?

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    There is something else going on as I also have MSP-EXP430G2 Rev 1.5 & DLP-7970ABP Rev 4.5 and am not able to auth the tag. I am going to review some LSA traces between Helfried's system and my own.

    And yes I am testing w/ Helfried's source code.

  • Hello Sunil,

    After reviewing the LSA traces from Helfried's working example and my own LaunchPad as well as source code, I was not able to trace the root cause for the issue from a firmware standpoint. My theory at this point is that the physical header connections for the BoosterPack is not allowing the DM1 signal to be transmitted as cleanly. 

    The example itself was never designed with the BoosterPack + LaunchPad interface in mind, and these RF signals are very sensitive. Small changes or delays could impact the reading. This is the first time we'd ever tried to do a Direct Mode 1 implementation of any sort with the BoosterPack. It would also explain why two identical sets of hardware would have differences.

    At this time, we are not in position to do re-development in order to solve the issue on the BoosterPack. The original firmware writer who had the in-depth expertise with Special Direct Mode is no longer part of the team and we do not have an equivalent expert. Furthermore, there is doubt that the issue can even be solved with firmware adjustments due to the unique nature of the header connection presuming that I am correct about the issue being rooted in the RF signal being transmitted over the BoosterPack header. We will add the item as a 'to-do' but as a low priority item, so I would not have a time estimate to when it will be tackled.

    While I understand this doesn't exactly help your situation, we are basing the decision of this being low priority off the fact that many customers have successfully designed their MIFARE Classic systems based on the app note without the TRF7970AEVM available and so right now we only see a very limited need.

    As far as a path forward for you, if you could design an equivalent to the TRF7970AEVM where the TRF7970A and MSP430F2370 are connected on the PCB and not via headers, I feel strongly that you will be able to make this system work. If it is feasible for you to design a test PCB based on our EVM reference design and you want to do a schematic review before fabrication, let us know and we can make sure the schematics are accurate.

  • Hi Ralph Jacobi,

    I am sorry to say, but I am really surprised and disappointed. I never expected this from TI or you. You provide an EVM DLP-7970ABP for TRF7970A but without testing its functionality completely. SDM and DM1 are one of the main operating modes of TRF7970A but it doesn't seems to support as TI and its documents claim. TI have updated the DLP-7970ABP to Rev4.5 specifically to support these modes. I wonder how it is not tested properly.  Still you are not sure about what the issue is. You are just assuming. You designed a board with headers for RF applications and selling it, but now assuming that the reason for the issue could be the headers, then why do you design and sell it with headers?

    I feel that "the original team that worked on this is no longer available" is not a proper excuse according to TI standards. There should be a proper knowledge transfer and coordination. Why do you sell a product if you are not ready to support it properly.

    We decided to go with this approach only after several confirmations from TI support executives and documents. None of it said that DLP-7970ABP is not recommended or suitable for Mifare application or SDM and DM1 modes.Issues are common thing in engineering and development but what is more disappointing is that you are saying that you are assigning it as low priority and not ready to solve it. Neuroptics have spent more than 5 months on this approach, we have spent a lot of time and cost in it. We made every step only after getting confirmation from TI. Now you are telling to start from the beginning once more.

    Please don't sell DLP-7970ABP from revision 4.5. Explicitly mention that it does not support SDM and DM1 modes and Application note SLOA214. Recommend to manufacture own TRF7970AEVM. This is my humble request, I don't want anybody else to fall in the same trap.

     

    Thanks and Regards,

    Sunil

  • Hello Sunil,

    Sunil Kumar Mohan kumar said:
    You provide an EVM DLP-7970ABP for TRF7970A but without testing its functionality completely. SDM and DM1 are one of the main operating modes of TRF7970A but it doesn't seems to support as TI and its documents claim. TI have updated the DLP-7970ABP to Rev4.5 specifically to support these modes. I wonder how it is not tested properly. 

    Few points to clarify here:

    1) The EVM is a third-party design and while we do work with them closely, it is not a TI design EVM. When it was designed - to my knowledge - this functionality was tested and confirmed to work. It certainly seems to work in some cases, as Helfried is having no issues with his setup. However, you and I are both observing problems. While I was around at the time of all of this, I was a new engineer on the team and I simply don't have the background of how decisions were made or test procedures done to really elaborate on how this issue escaped notice.

    2) SDM and DM1 are not what we consider main operating modes. They are additional modes available for the benefit of extra non-NFC applications. However, Direct Mode 2 is the main operating mode and what our focus on support is for. We are primarily targeting this device to markets that use technologies like the TI-produced ISO15693 tags as general RFID applications, and NFC application that are compliant with NFC Forum Standard firmware.

    All that said, we saw value in using SDM and DM1 for MIFARE Classic and put together a detailed app note with software to support it. Up to this point, the MIFARE Classic support we have offered has been more than enough for many customers to go into high volume production, and the level of support I provided which Helfried & I have extended to you was sufficient to solve technical challenges.

    Sunil Kumar Mohan kumar said:
    You designed a board with headers for RF applications and selling it, but now assuming that the reason for the issue could be the headers, then why do you design and sell it with headers?

    That is the only assumption I can make at this given the nature of the signals in play and that there is zero difference in system setup for Helfried and I that we can identify. That said, the hardware has been out for almost 5 years now and this issue is only now being brought front and center. If this had been known years ago, we may have made different decisions about our EVM offerings and marketing of features.

    Sunil Kumar Mohan kumar said:
    I feel that "the original team that worked on this is no longer available" is not a proper excuse according to TI standards. There should be a proper knowledge transfer and coordination. Why do you sell a product if you are not ready to support it properly.

    I will mention your concerns to management. There is a limit to knowledge transfer and coordination though. I am well versed in how it should work but I never wrote the firmware and cannot have the same level of intimate understanding of how the firmware behaves to know every single delay to potentially adjust here. I'm sorry that is the case, but there are limits to the support we can provide.

    Again the key here is that the EVM boards are not working as expected together. The firmware runs perfect on the TRF7970AEVM, and it runs on many customers hardware as well. So it is not that we completely lack knowledge or cannot support it on a device level which is our primary obligation.

    Sunil Kumar Mohan kumar said:
    Issues are common thing in engineering and development but what is more disappointing is that you are saying that you are assigning it as low priority and not ready to solve it. Neuroptics have spent more than 5 months on this approach, we have spent a lot of time and cost in it. We made every step only after getting confirmation from TI. Now you are telling to start from the beginning once more.

    I will bring this up as well.

    What I wish I could do right now is provide you a TRF7970AEVM because that works for certain. Unfortunately due to COVID-19 I cannot do so for the foreseeable future, and I do not know when restrictions will lift to the point I could do this for you. Under any other circumstance, I would have done this as soon as it became clear the issue was with the BoosterPack hardware...

    Sunil Kumar Mohan kumar said:
    Please don't sell DLP-7970ABP from revision 4.5. Explicitly mention that it does not support SDM and DM1 modes and Application note SLOA214. Recommend to manufacture own TRF7970AEVM. This is my humble request, I don't want anybody else to fall in the same trap.

    Revising the app notes is going to be an action we need to take out of this promptly if further investigation is not going to be done immediately, I agree 100%.

**Attention** This is a public forum