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 EVM and MSP430F2370 programming

Other Parts Discussed in Thread: TRF7960A, MSP430F2370, MSP-FET, TRF7960, MSP-TS430QFN23X0, TRF7970A, DLP-7970ABP, MSP430G2553, MSP430F5529, MSP-EXP430F5529LP, MSP-GANG, CC2630, CC2650

Hi

We have acquired the TRF7960A EVM Rev.A evaluation board and this triggers some questions.

It works perfectly on a standalone basis but we understand it’s not a development board. In other terms it sounds like it’s not possible to flash our own program into the MSP 430F2370 installed on the board.

Alternatively we have identified the TRF7960A Target Board that seems to be dedicated to the development of RFID applications.

Questions

  • Are we right doing the assumption that the TRF7960A EVM does not allow MSP430 programming?
  • Is it possible to find the source code loaded into the MSP430F2370 implemented on the TRF7960A EVM evaluation board? Can it be read using the MSP-FET?
  • Using the TRF7960A Target Board, we assume that loading our own program into the MSP 430 memory will erase the original TRF7960 communication stack implemented. Is there a way to revert to factory settings?
  • In other words can we upload what is originally implemented in the MSP 430 to save and restore it?
  • Is the JTAG/MSP-FET interface the only solution to download programs in the MSP 430?
  • What would be the suggested development board to use in connection with the TRF7960A EVM board, knowing that we want to use the MSP 430F2370 to manage sensors in addition to TRF7960A communication?

Finally, in the perspective of developing our prototypes we’ll need to flash MSP 430F2370s with our own program and implement them on our boards.

Questions

  • Is the MSP-TS430QFN23x0 (the target board for the MSP430F2370) the right board to do so?
  • Is there a better alternative to this board?
  • Is it better to load the MSP430 with its program prior to soldering or should we implement a JTAG interface on our board to do the programming once the complete board is fully soldered?
  • Hello,

    I will address each of your questions, but beforehand I want to note that based on your description about your needs for development that there are other platforms which you may be interested in trying out. Depending on what NFC functionality you wish to have in your system, and what code size requirement you have, we have evaluation platforms with example code available for a few MSP430 LaunchPad boards which pair with our DLP-7970ABP BoosterPack for the TRF7970A.

    • If you want to develop with a cheap but resource-limited MCU for just Reader/Writer functionality, there is the MSP-EXP430G2 LaunchPad which uses an MSP430G2553 MCU (16kB Flash, 512 bytes RAM)
    • If you want a robust development platform capable of supporting all NFC modes, there is the MSP-EXP430F5529LP which uses an MSP430F5529 MCU (128kB Flash, 8kB RAM)
      • Code examples for this include our full NFC stack which support Card Emulation, Reader/Writer, and Peer-to-Peer. You can find the latest firmware for that in our Reader/Writer application note: http://www.ti.com/lit/an/sloa227/sloa227.pdf

    Also, all of our latest NFC software examples exist for the LaunchPad platforms while the TRF7960AEVM examples are quite outdated by now since all our new firmware development is geared towards our newer part, the TRF7970A.

    Regarding your first round of questions:

    1. You can program the MSP430F2370 by using an MSP-FET JTAG Programmer and Code Composer Studio or IAR Workbench (All our code examples are for Code Composer Studio)
    2. You can find the source code the TRF7960AEVM on the EVM's tool page near the bottom: http://www.ti.com/tool/TRF7960AEVM (Click on "Show More")
    3. Yes loading your own program will erase the original TRF7960A stack, but you can revert it using the firmware examples mentioned above.
    4. You can use the original firmware examples, modify them for your application, and then program the MSP430F2370 that way. This can be done with any of our provided example code including the newer software example I mentioned at the beginning of this post.
    5. Yes, the EVM is configured so that JTAG and MSP-FET is the only way to write firmware into the MSP430F2370 on the TRF7960AEVM
    6. If you would like to use Sensors with your design, I recommend moving to our LaunchPad platform which will provide you many different GPIO's which are broken out in order to allow you to connect your sensors and interface with them.

    Second wave of questions:

    1. I believe that target board would be your best bet if you want to stick with the MSP430F2370 rather than use a LaunchPad platform for development.
    2. I don't know of any other options for the MSP430F2370 specifically.
    3. I am not sure I fully understand this question, are you referring to how to program the MSP430 for a final product?

    www.ti.com/.../sloa227.pdf

  • Thanks Ralph, your answers were quite clear and helpful.

    Regarding your remark #3, in your reply to our second wave of questions.
    • Indeed, our question was raised in the perspective of a future production process:
     Should we preload the MSP430 with its program prior to soldering or should we implement a JTAG interface on our board to do the programming once the complete board is fully soldered?
    • We assume that for pre-production programming, a device such as the MSP-Gang would have to be considered?

    Additional question:
    Knowing that our RFID module will communicate wireless with a master, using the Zigbee protocol, we will have a CC2650 (or a CC2630) on our board.
    Could we use the CC2650 to manage also the TRF7970A (instead of the MSP430F 5529), or should it be dedicated to managing the Zigbee stack only?
    Note: our network will be meshed so each node will have to route packets and will not behave only as an end device.
    In this perspective, would the CC2650DK dev board allow us to test the integration of the TRF7970A as well?

    Best Regards

    Jean-Christophe Sauniere
  • Hi Jean-Christophe,

    Either option is a possibility as far as production goes. You can have the MSP430 pre-programmed by your distribution supplier, or use JTAG and program it in house yourself with a JTAG interface after the MSP430 is soldered on. You may also want to consider having a JTAG circuit even if the part is pre-programmed to enable the ability to update or patch the firmware?

    Regarding the CC2650, depending how much space you have available, it should be possible to use it to manage the TRF7970A. However, we have not done this and have no examples for that platform. Regarding the CC2650DK in particular, I am not familiar with that dev kit, so make sure to verify that the SmartRF06 boards have the connections needed for the TRF7970A (SPI lines, IRQ, GPIO for EN pin, etc) broken out first. If so then you should be able to blue wire the DK to a BoosterPack.
  • Hi,

    We are planning to interface NFC chip TRF7970a with cc2650 , i have following queries regarding that,

    First of all is there any sample example in interface trf7970a with cc2650?

    Does cc2650 is adequate (in terms of flash and ram)  to run ble stack and nfc stack ?

  • Hi Hardik,

    What NFC modes do you plan to run on the CC2650?

    We don't yet have a code example for the TRF7970A and CC2650, but I can at least provide insights on the memory required for NFC depending on which modes you plan to use.
  • Hi ,

    We are using iso14443A type 2 tag.

  • Hi Hardik,

    It would be possible to add that functionality to the CC26xx. Since you will be an initiator and reading tags you can dictate the communication timings. You should be able to set up the RTOS task manager to run the BLE tasks at highest priority and NFC/RFID reader task as the next highest and then read the tag that way.

    As I mentioned before, we don't have any firmware examples for this at this time.

    Size wise, depending on how robust the application needs to be it would take anywhere from ~30kB of Flash space (full and robust error handling for positive/negative cases) to as little as maybe 8kB for basic RFID reader functionality with simple error handling.