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.

CCS/RF430FRL152HEVM: FRAM Raed /Write issue

Part Number: RF430FRL152HEVM
Other Parts Discussed in Thread: RF430CL331H, RF430CL330H, RF430FRL152H

Tool/software: Code Composer Studio

Hi,

I am using RF430FRL152HEVM kit for NFC communication with mobile phone. I want to perform read and write operation from mobile phone to RF430FRL152HEVM kit.

I have tried example from below PATH:
slac691f\RF430FRL15xH_Projects_v1_5\RF430FRL15xH_Projects_v1_5\RF430FRL15xH_Projects_v1_5\RF430FRL15xH NFC Projects\RF430FRL152H

I am Facing problem for FRAM writing in Run time. 

source code is:

MEMORY
{
    SFR                     : origin = 0x0000, length = 0x0010
    PERIPHERALS_8BIT        : origin = 0x0010, length = 0x00F0
    PERIPHERALS_16BIT       : origin = 0x0100, length = 0x0100
    RAM                     : origin = 0x1C00, length = 0x1000

    //ROM ISRs, starting points, length not correct
    RF13M_ROM_ISR			: origin = 0x54D0, length = 0x0002

    // code area, can be increased /  decreased
    // FRAM_NDEF + FRAM_CODE lengths must equall 0x768 (with FRAM_NDEF starting at 0xF868)
    // Two sections together in the range of 0xF868-0xFFCF 
    FRAM_NDEF               : origin = 0xF868, length = 0x0096 // ends at 0xF8CF - NDEF memory section
    FRAM_Data               : origin = 0xF8FE, length = 0x00A0 // ends at 0xF8CF - NDEF memory section
    FRAM_CODE               : origin = 0xF99E, length = 0x0630 // ends at 0xFFCF - Firmware memory section
    JTAGSIGNATURE           : origin = 0xFFD0, length = 0x0004, fill = 0xFFFF
    BSLSIGNATURE            : origin = 0xFFD4, length = 0x0004, fill = 0xFFFF
    INT00                   : origin = 0xFFE0, length = 0x0002
    INT01                   : origin = 0xFFE2, length = 0x0002
    INT02                   : origin = 0xFFE4, length = 0x0002
    INT03                   : origin = 0xFFE6, length = 0x0002
    INT04                   : origin = 0xFFE8, length = 0x0002
    INT05                   : origin = 0xFFEA, length = 0x0002
    INT06                   : origin = 0xFFEC, length = 0x0002
    INT07                   : origin = 0xFFEE, length = 0x0002
    INT08                   : origin = 0xFFF0, length = 0x0002
    INT09                   : origin = 0xFFF2, length = 0x0002
    INT10                   : origin = 0xFFF4, length = 0x0002
    INT11                   : origin = 0xFFF6, length = 0x0002
    INT12                   : origin = 0xFFF8, length = 0x0002
    INT13                   : origin = 0xFFFA, length = 0x0002
    INT14                   : origin = 0xFFFC, length = 0x0002
    RESET                   : origin = 0xFFFE, length = 0x0002
}

/****************************************************************************/
/* Specify the sections allocation into memory                              */
/****************************************************************************/

SECTIONS
{
    GROUP(ALL_FRAM)
    {
       GROUP(READ_WRITE_MEMORY)
       {
        // .TI.persistent : {}    >FRAM_Data            /* For #pragma persistent            */
          .cio        : {}                   /* C I/O buffer                      */
          .sysmem     : {}                   /* Dynamic memory allocation area    */
       }

       GROUP(READ_ONLY_MEMORY)
       {
          .cinit      : {}                   /* Initialization tables             */
          .pinit      : {}                   /* C++ constructor tables            */
          .init_array : {}                   /* C++ constructor tables            */
          .mspabi.exidx : {}                 /* C++ constructor tables            */
          .mspabi.extab : {}                 /* C++ constructor tables            */
          .const      : {}                   /* Constant data                     */
       }

       GROUP(EXECUTABLE_MEMORY)
       {
          .text       : {}                   /* Code                              */
       }
    } > FRAM_CODE

    .rf13m_rom_isr		: {} > RF13M_ROM_ISR type = DSECT

    .jtagsignature : {} > JTAGSIGNATURE   /* JTAG Signature                    */
    .bslsignature  : {} > BSLSIGNATURE    /* BSL Signature                     */
    .jtagpassword                         /* JTAG Password                     */

    .bss        : {} > RAM                /* Global & static vars              */
    .data       : {} > RAM                /* Global & static vars              */
    .TI.noinit  : {} > RAM                /* For #pragma noinit                */
     .TI.persistent : {}    >FRAM_Data            /* For #pragma persistent            */
    .stack      : {} > RAM (HIGH)         /* Software system stack             */

    /* MSP430 Interrupt vectors          */

    .int00       : {}               > INT00
    .int01       : {}               > INT01
    .int02       : {}               > INT02
    .int03       : {}               > INT03
    .int04       : {}               > INT04
    RFPMM        : { * ( .int05 ) } > INT05 type = VECT_INIT
    PORT1        : { * ( .int06 ) } > INT06 type = VECT_INIT
    SD_ADC       : { * ( .int07 ) } > INT07 type = VECT_INIT
    USCI_B0      : { * ( .int08 ) } > INT08 type = VECT_INIT
    ISO          : { * ( .int09 ) } > INT09 type = VECT_INIT
    WDT          : { * ( .int10 ) } > INT10 type = VECT_INIT
    TIMER0_A1    : { * ( .int11 ) } > INT11 type = VECT_INIT
    TIMER0_A0    : { * ( .int12 ) } > INT12 type = VECT_INIT
    UNMI         : { * ( .int13 ) } > INT13 type = VECT_INIT
    SYSNMI       : { * ( .int14 ) } > INT14 type = VECT_INIT
  	.reset       : {}               > RESET  /* MSP430 Reset vector         */
}
--------------------------------------------------------------------------------------------
Main.c file:

#pragma RETAIN(FRAM_arr);
#pragma location = 0xF8FE;
//#pragma DATA_SECTION(FRAM_arr, ".TI.persistent")
#pragma PERSISTENT(FRAM_arr)
unsigned char FRAM_arr[50];


Main()
{
------
------

	for(count = 0; count<21;count++)
	{
	    FRAM_arr[count]= count;

 }
----
----
}

At run time i am writing FRAM memory . Upadted data is also showing in CCS memory during debugging tool. But after reset command , this data is erasing every time. 

Can you please suggest the mistake , i am doing here . 

Thanks,

Anil Garg

  • Hello Anil,

    I am not sure the purpose of the #pragma PERSISTENT calls, I don't recall those being used in any of our example codes. Can you explain what that is intending to do that RETAIN does not?

    I would need to try out the firmware in the office tomorrow to offer further comments.
  • Hello Anil,

    I have not been able to re-create your issue on my end. After power cycle, data is being correctly retained in the location specified. I even wrote a large NDEF message which overwrote that segment, power cycled the device, and the data in the segment was updated per the while loop.

    One thing I did notice with your code is you don't have a ; at the end of your #pragma PERSIST - perhaps that is the issue? I would have expected a compiler error though, but if you didn't get one and that semi-colon is still missing, that is the only thing I can think that could be the issue as I am using the same buffer at the same memory location with the same filling and haven't had any problems like you are describing.
  • Thanks for your response.

    I am able to read and write FRAM if i access the memory indirectly by pointer.

    some more query here 

    1. If i write NDEF memory using any Reader/writer then how to detect NDEF write operetaion in RF430FRL152 ?

    Means using which SFR or control bit , i could confirm that NDEF memory is updated by any external device.

    2. I have tried example from below PATH:

    slac691f\RF430FRL15xH_Projects_v1_5\RF430FRL15xH_Projects_v1_5\RF430FRL15xH_Projects_v1_5\RF430FRL15xH NFC Projects\RF430FRL152H

    NDEF read and write is working fine If i  don't comment __bis_SR_register(LPM3_bits + GIE); line

    But if i comment this line (__bis_SR_register(LPM3_bits + GIE);) then it stops working (read and write both)

    If i update line with __bis_SR_register(GIE); then NDEF read operaton is happening but write operation (from reader writer kit) is not happening . why?

    Thanks

    AG

  • Hello Anil,

    Anil Garg said:
    1. If i write NDEF memory using any Reader/writer then how to detect NDEF write operetaion in RF430FRL152 ?

    I think the closest operation to this would be to monitor the RF stack via RF13MINT and determine when receive operations are complete. There isn't any special handling for the NDEF within the device functionality though so checking that an NDEF operation occurred and what changed would be application specific.

    Anil Garg said:
    If i update line with __bis_SR_register(GIE); then NDEF read operaton is happening but write operation (from reader writer kit) is not happening . why?

    This seems to be limited to your application somehow. I did this change with the NDEF example and tested both NDEF read and NDEF write and had no issues. I am not sure why that would change the behavior for you however as removing the LPM3 should have no impact...

  • Actually the only thing I can think of is maybe if you are using a weak reader/writer, that without running in LPM3 mode, the device can't sustain power from the RF field when write operation occurs. That would only apply if you are powering the board over RF though. Just a brief thought.
  • Hi,

    If processor want to read/write NDEF memory in application code and on same time Reader/writer is also accessing same memory , then how to sync the both tasks simultaneously?

    Is there any provision of interrupt flag which provide status of NDEF memory read/write operation completions? If yes then what will be sequence of handling?

    Can you suggest any strategy with which micro controller can read NDEF memory if it is modified by any reader/writer at run time?

    can we make seperate partition of NDEF memory for read and write operation?

    It will be more better if share the example code.

    Thanks,
    AG
  • Hello Anil,

    Such a use case has not come up for the RF430FRL15xH devices before, so it is difficult for me to say for sure. It is not the usual use case at all and was not part of design considerations as the I2C/SPI interface was designed more to be used for Host intentions with slave Sensor devices.

    My best suggestion would be to monitor the RF stack interrupts and if there is no activity then to do the writes, and when activity occurs, then stop the writes.

    Honestly if that is your requirement, you should look at the RF430CL330H or RF430CL331H instead. Those devices have the exact features you need to handle such an application as they have dedicated pins for alerting when NFC communications begin.

    Because we have the above device, we are not going to investigate how to achieve the same with the RF430FRL152H as it is, as mentioned before, outside of the intended use case for the device.
  • I have not selected RF430CL330 because of two reasons:
    1. Communication RF range is less compared with RF430FRL152.

    2. Non availability of non volatile memory.


    Can you share any documents which helps to understand the sequence of RF430_ISR handling during NDEF read write operation with RF430FRL152?

    Thanks,
    Anil
  • Hello Anil,

    The RF430CL330H is often paired with FRAM MSP430 devices to offer the non-volatile memory feature. This is best seen in the TI design for the RF430CL331H where an FRAM MCU is used to log 40kB+ of sensor data that can be transmitted over NFC.

    I bring this up because I am concerned you ultimately will hit a wall with your intended use because it's so divergent from anything we considered during IC design.

    As far as documentation for the RF430 ISR's for the RF stack, you would need to reference Section of our Technical Reference Manual: www.ti.com/.../slau506.pdf

    13.2 walks through the whole operation of the RF stack, and 13.3 lists the registers including all the interrupt flags.

    Keep in mind that the RF stack won't recognize individual NDEF commands, they will just be seen as ISO15693 commands such as Read Single Block and Write Single Block, so if you actually need to track NDEF specific commands such as Read CC or Select Application etc. that will add another layer of complexity where you'd have to handle that at an application level by reading out the FIFO contents and decoding the received packets to understand what bytes are being accessed and then mapping that to the NDEF header/payload.
  • 1. What will be effectivily communication range (maximum distance between dynamic tag and reader writer) proposed with RF430FRL15x and RF430CL330x respectively.

    2. Shared reference technical manual of rf430frl is little complex for understanding the sequence of interrupt handling. So please share and reference source code or guide me to implemente the suggested strategy (NDEF detection).

    3. How data security is provided in rf430frl15x?
    Thanks,
    AG
  • Hello Anil,

    1) That is very system dependent, as the read range will depend on many factors such as:

    • Passive power or battery power
    • Antenna size for tag and reader (i.e. how well the antennas couple)
    • Reader device antenna tuning*
    • Reader device output power
    • Potentially, how much data needs to be transferred, if being passively powered

    In general, ISO15693 technology provides better range, but the * I put next to reader device antenna tuning is to call out that in particular that is a very key factor as the range benefits for the passive tag can only be realized if the Reader device is specifically tuned only for ISO15693 technology. If it needs to support other technologies like ISO14443A, then you won't be able to realize any of the range benefits anyways.

    2) We do not have any such guides, and will not be providing such. As mentioned, what you are trying to achieve is outside of the intended use cases for the device. If it is possible, the TRM contains the information needed to accomplish your goals, but we are not going to invest time on our end to investigate a niche application that is beyond what we intended the device to be used for. Sorry that this answer is not ideal for you.

    3) There really isn't any data security provided, the only security offered is 'security by proximity' - i.e. that someone has to be within the read range of the device to access the data. This especially the case for data that needs to be available over RF for authorized devices. I explained the full details of what is and isn't possible in this post: https://e2e.ti.com/support/wireless_connectivity/nfc_rfid/f/667/p/676283/2489612#2489612