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.

RF430FRL152H: safely writing to memory using ISO15693 Block Write

Part Number: RF430FRL152H
Other Parts Discussed in Thread: MSP-EXP430G2ET, DLP-7970ABP

Hi,

For my application, I would like to write some configuration parameters (just a few bytes, really) to the RF430FRL152H using an external transceiver. I have configured a MSP-EXP430G2ET + DLP-7970ABP to write to some portion of the FRAM memory, for example writing a few bytes starting at NDEF block 0x0A. (I don't care about having a properly formatted NDEF message, as this device will only be used with a custom transceiver. I just want to stick the configuration parameters somewhere the firmware can have access & where they can be read/verified via ISO15693 commands)

My NFC_NDEF_Message section of FRAM initially looks like

and then after I've written to 3 blocks (using ISO15693_sendWriteSingleBlock) starting at block 0x0A I see the memory contents update:

This all works well, except that when the MCU restarts (e.g. after a soft reset or power cycle) the application fails to run (CCS debugger shows program counter at random locations, device doesn't respond to further ISO15693 commands). I suspect that I'm interfering with some aspect of the ROM or perhaps tripping CRC verification? If so, could you advise on why this is happening and if there is a "safer" approach or memory location I should be using?

Thanks,

Jason

  • Hello Jason,

    Okay so I'm a bit confused here because it sounds like you are crossing two different applications here.

    For configuring the device via virtual registers, you cannot be in NFC/NDEF mode. If that is the situation, then you have to pick one or the other. Either a non-NFC setup with virtual registers, or using NDEF messaging and not having access to the virtual registers.

    If I am mistaken about this, please help clarify which example project you are working from so I can look into it further.

    Also the reader side, I am guessing you are using SLOC297 and the ISO15693_sendWriteSingleBlock API?

  • Hi Ralph,

    Thanks for the quick response!

    For configuring the device via virtual registers, you cannot be in NFC/NDEF mode. If that is the situation, then you have to pick one or the other. Either a non-NFC setup with virtual registers, or using NDEF messaging and not having access to the virtual registers.

    I want to use NFC/NDEF mode, not the virtual registers. When I wrote "configuration parameters", I'm talking about some functionality specific to my application (I actually want to configure the parameters of a PWM module) which is not supported by the main application.

    If I am mistaken about this, please help clarify which example project you are working from so I can look into it further.

    I am working off the NFC_Only sample application. One thing that might be relevant is that I changed the size of the FRAM_NDEF and FRAM_CODE sections in the linker file:

        // 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 = 0x0018 // ends at 0xF8CF - NDEF memory section
        FRAM_CODE               : origin = 0xF880, length = 0x0750 // ends at 0xFFCF - Firmware memory section

    Also the reader side, I am guessing you are using SLOC297 and the ISO15693_sendWriteSingleBlock API?

    Yup, that's right. But really I am not tied to using ISO15693, if it's easier to accomplish with custom commands I could do that instead. The only reason I used ISO15693 was because it's what was supported in SLOC297.

    Thanks,

    Jason

  • Hello Jason,

    Okay that explains the rest clearly to me, thank you for that.

    Looking at the memory map and where the bytes are changing, you have exceeded your FRAM_NDEF space and are into the FRAM_CODE space, so that's whats causing the restart issue.

    Can you share the ISO15693 API's you have written in SLOC297 to write the data? I should be able to see where the mapping is wrong by looking at that.

  • Hi Ralph,

    Obvious now that you point it out! I adjusted the block number I am writing to and that seems to have fixed it.

    On the SLOC297 side I have modified the NFC_appIso15693 function a bit as shown below. (Note, I defined START_BLOCK as 0x0A. But I adjusted to use 0x02 and this seems to fix the problem.)

    ...
    if (ui8TagFound == STATUS_SUCCESS) { if (ISO15693_getTagCount() > 1) { #ifdef ENABLE_HOST UART_putNewLine(); UART_sendCString("Multiple ISO15693 Tags Found"); UART_putNewLine(); UART_sendCString("# of Tags Detected: "); UART_putByteDecimalValue(ISO15693_getTagCount()); UART_putNewLine(); UART_sendCString("Place only 1 tag in RF Field to read data"); UART_putNewLine(); #endif } else { unsigned int block_num = 0; for (block_num = START_BLOCK; block_num < START_BLOCK+2; block_num++) { if (ISO15693_sendReadSingleBlock(0x02 | ui8AddressedFlag, block_num) == STATUS_FAIL) // Keep reading blocks unless a No Response is received { LED_15693_OFF; // No Response - stop reading break; } } if (NFCwrite()) { // NDEF Header uint8_t b1[4] = {0xE1, 0x40, 0x79, 0x00}; uint8_t r = ISO15693_sendWriteSingleBlock(0x42 | ui8AddressedFlag, 0x00, 4, b1); uint8_t b2[4] = {0x03, 0x0B, 0xD5, 0x00}; r = ISO15693_sendWriteSingleBlock(0x42 | ui8AddressedFlag, 0x01, 4, b2); uint8_t* p = getNFCPayload(); // returns a pointer to the new data to be written to the tag unsigned int num_bytes = 12; unsigned int block_num = START_BLOCK; while (num_bytes > 0) { unsigned int bytes_to_write = 4; uint8_t b[4]; memcpy(b, p, 4); r = ISO15693_sendWriteSingleBlock(0x42 | ui8AddressedFlag, block_num, bytes_to_write, b); block_num += 1; p += bytes_to_write; num_bytes -= bytes_to_write; } } } }

    As one last question then, am I correct in assuming I can use the NDEF memory as arbitrary storage in the NFC_Only example?

    Thanks,

    Jason

  • Hello Jason,

    Jason Wright said:
    As one last question then, am I correct in assuming I can use the NDEF memory as arbitrary storage in the NFC_Only example?

    Well, you can, but it would be odd to go through NDEF for that unless your end goal is to use a Smartphone to read data and need NDEF for that, but even then the Smartphone would need to do how to process that data once it's read?