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.

  • TI Thinks Resolved

CCS/RF430FRL152H: issue about RF430FRL152H

Expert 8075 points

Replies: 3

Views: 105

Part Number: RF430FRL152H

Tool/software: Code Composer Studio

Dear team,

Please check the following questions:

1 Can basic instructions such as Inventory be rewritten? Can UID be defined by myself?

2 Can the programming of rewriting Code be completed through the TRF7970A air interface, or does it require additional equipment to program through jtag?

BR,

SUSAN

  • Hello Susan,

    the UID of the device can not be defined by the customer, this is data that is programmed by TI and locked.

    From my understanding it should be possible to rewrite also the basic instructions. When you look into the code examples for the RF430FRL152 you will find a file patch.c which contains a fix for a ROM command which uses the patching mechanism which is described in the Firmware Users Guide (page 58):

    http://www.ti.com/lit/pdf/slau603b

    With this mechanism it is also possible to define custom command.

    The programming can be done "over the air" as long as the interrupt table does not get corrupted which points to the NFC stack. In this case the NFC communication is lost and the only way to get access to the device again is via JTAG.

    For a development a good start would be the RF430FRL152HEVM which contains also the level-shifters for the JTAG interface which are necessary because of the low supply voltage of the device.

    https://www.ti.com/tool/RF430FRL152HEVM

    In addition the MSP-FET Tool  is needed.

    https://www.ti.com/tool/MSP-FET

    Regards,

    Helfried

     

  • In reply to Helfried Vollbrecht:

    hi,Helfried,

    Thanks for your reply,

    You means device descriptors (TLV) is read-only memory, but I can use the example in path. C to redefine the inventory command stack.

    If Command ID has only the high byte defined (for example, 0xNN00), then this represents

    a ROM function to be patched. This functionality is described for informational purposes
    only; the user is not expected to make changes to the ROM functionality.

    I didn't find any documentation about the basic instructions, such as how to access the 15693 state machine, associated API  address, etc

    sometimes,  I'll just want to change the function a bit and then continue to call ROM function

    if ((Firmware_System_Control_Byte & FIRST_ISO_PAGE_MASK) == FIRST_ISO_PAGE)

    {
    asm (" add.w #0xF840, R10");
    }
    else
    {
    asm (" add.w #0xF850, R10");
    }
    asm (" mov.b #0x1, R14 " ); //correction
    asm (" br #0x544E ");
    }
    else
    {
    asm (" br #0x542C "); //Call the ROM function, no fixes necessary
    }

    In addition, Is it possible to destroy the programming function of "over the air" by using this method?

    Best Regards

  • In reply to horace du:

    Hello Horace,

    because I do not have a deeper knowledge about that mechanism I can only point you to the documents available.

    I tried to find someone more experienced with that but without luck. The patching mechanism was seldom used by customers and then for implementing custom commands and not for patching the build in command. Seems I can not help you further in this case.

    Regarding your question about destroying the "over the air programming", as long as the IRQ table does not get corrupted and the Write Block command is still functional, it should work.

    Regards,

    Helfried

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.