• Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 1119 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.

Error in SLOC203 code for TRF7960AEVM

Phil Ekstrom
Intellectual 640 points
Other Parts Discussed in Thread: TRF7960A, TRF7970A, TRF7960, TRF7962A, MSP430G2553

Moving the code in sloc203 (TRF7960A EVM firmware), originally for CCS into a form that would compile in IAR, I got a compiler warning on line 351 of file host.c  "comparison always true". The line was: if(pos++ < 2 * BUF_LENGTH). 

Sure enough, in line 215 of host.c the variable pos was declared as unsigned char, and in globals.h the symbol BUF_LENGTH was defined as 300 so the comparison WAS always true and the check for buffer overrun would fail. Changing pos to an unsigned int fixed the problem. The code should now actually accept no more than 600 nibbles/300 bytes, as appears to be intended.

Has no one tried to compile that code lately? An update to the package would seem to be in order. What code is actually in the EVM as supplied?

  • TI__Guru*** 128465 points
    Hi Phil,

    I apologize for the delay in getting back to you on this.

    That is a very old firmware example so it hasn't been updated or referenced in a long time. I loaded the code into CCS myself and got no such error on compile, but you are correct in what you have said. I believe that firmware is in the EVM that is supplied but I'd have to check.

    The TRF7960A is an older version of our TRF7970A product, so while we do support it as it is a released part we are not making any further development to the example code and software packages for the TRF7960A at this time. All our new development is for the TRF7970A. That said, thank you for pointing out this issue so we can revisit that issue internally.
  • in reply to Ralph Jacobi
    Intellectual 640 points
    Ralph,

    Ah, that sounds like I should be designing in the 7970, not the 7960.

    SLOA158 (7960 and 7970 comparison) seems to say that most of the 7970 improvements concern ISO14443A operation. I will only be using ISO15963, so the main reason would be to get the SPI polarity reversal fix and to move to a newer part that is getting more attention. Probably still worth the change, even this late.

    But I do want to start with a copy of the support firmware used in the corresponding EVM. While the 7970 Reference firmware description promises source code for that firmware, I do not seem to find it on the TRF7970aevm page where the link takes me. On the corresponding 7960 page I find "TRF7960 Firmware Source Code for CCS" sloc203.zip which I was porting over to IAR when the pickier IAR compiler gave me that tip-off warning message.

    What is the corresponding zip file for the 7970EVM firmware?
  • in reply to Phil Ekstrom
    TI__Guru*** 128465 points

    Hi Phil,

    Depending on your application it certainly can still can make sense to use the TRF7960A and it's subset parts. For example, if you just want to use ISO15693 reader/writer only, then something like the TRF7962A (http://www.ti.com/product/TRF7962A) would be a great fit for you. There wouldn't be any difference between the TRF7970A and the TRF7962A besides the FIFO size and SPI Polarity issue. Also each of our parts are fully pin compatible, so you could evaluate with the TRF7970A and latest/most robust firmware to ensure your functionality from the RFID aspect is met and then address the small fixes to use the firmware for the TRF7962A for your final project. Does this method make sense?

    Regarding the firmware to use for the TRF7970A there are a couple options for you.

    1. The latest firmware developed is for the TRF7970A BoosterPack (DLP-7970ABP) and the MSP430-EXPG2 LaunchPad (using MSP430G2553) which handles basic RFID reader capabilities for ISO14443A/B, ISO15693, and FeliCa. It is set up to be modular and you are fairly easily trim it down all the way down to only ISO15693 mode. The ISO15693 firmware has been extensively tested including an space optimized method for tag anticollision (to cut down on required RAM space) so I think it would be best to use that firmware.
      1. The latest firmware will be on the web very soon, but for now please download it from here: 3125.TRF7970ABP_RFID_Reader_Demo.zip
    2. The ISO15693 functionality for the TRF7970AEVM is good, but the firmware base itself is a dated as well, and can be hard to read/understand at times when inside the compiler. That said, the hooks for the SPI Polarity reversal are still within the firmware, so it would be a good basis to look at if you start with the code mentioned in point 1 and then need to apply the polarity fix.
      1. The firmware for the TRF7970AEVM Firmware can be found at: http://www.ti.com/lit/zip/sloc300 (listed as "TRF7970A C Code Example (Rev. A)" on the EVM page)

    Also just a general note about the 'tip-off' message you got - that was for a file related to the GUI interface, not the ISO15693 functionality. If you have no need for the GUI that wouldn't affect anything anyways. Also I never compared the GUI setup for the TRF7970AEVM vs the TRF7960AEVM, so the same line may appear for the TRF7970AEVM files as well, but again if you aren't using the GUI for your final project it wouldn't affect anything.

  • in reply to Ralph Jacobi
    Intellectual 640 points

    Thanks, Ralph!
    I think you have everything for me that I need. I might suggest, though, a name change for sloc300 that identifies it as the EVM firmware.

    Just a word about what I'm doing and why. I'm going to use the TRF7970 (or perhaps another family member as you suggest) for access to an ISO15693 tag (based on your RF430FRL153). During production I will in one situation be copying information from a PC into the tag that will form part of a product of ours. For that I would use your '70EVM, or failing that use one of your booster packs if I could find one with an SD16 or SD24 module implemented. However there are cryptographic protocols involved and  I need a good source of entropy on-chip in the host processor. The low end of the filter output register of those two SD modules works admirably as an entropy source, a hack I documented in another thread. So to get that entropy source I have designed my own booster pack host for the '70ATB (or '60ATB), and will be in some cases talking to its serial port with a USB bridge chip, just like one does to the '70EVM. As a result I am especially interested in the '70EVM firmware, and the buffer handling error is directly relevant to my prospective use in production, though not to use in the field.

    I will use a TRF79xx built directly into the unit that hosts the tagged product in the field, so will obey your rules about keeping the ATB units at home.

    I am not sure that I succeeded in flagging your previous post as "question answered", but you certainly did that. Thanks again.

    Phil