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: Are the programs of RF430FRL152H and RF430FRL154H compatible?

Part Number: RF430FRL152H
Other Parts Discussed in Thread: RF430FRL154H, , MSP-FET

Hi,

I modified the code of the digital sensor in RF430FRL152H_SensorHub, and it runs very well on RF430FRL152HEVM. Since I don’t have a new RF430FRL152H now, I want to replace it with RF430FRL154H. I used air programming to directly compile the txt version of this code into RF430FRL154H, and it showed that the compilation was successful, but it did not seem to work when testing the digital sensor. So, is there anything that needs to be modified in the program? (For example, SD14, 154H should not have these ADCs) If it is fully compatible, I think there may be a problem with my connection, I will check the line.

Best Regards,

Zhixiong CHEN

  • Hello Zhixiong,

    I think the RF430FRL154H should be compatible for the sensor hub control, as the communication is done via I2C, which is also available on RF430FRL154H.
    I’m not sure if any remaining ADC code lines in the modified RF430FRL152H SensorHub Project might cause violations.
    You could try to remove them and recompile as RF430FRL154H project.

    Best regards,
    Andreas.

  • Hello Andreas,

    I checked the manual and found that this should be the problem:
    ROM sensor support application functionality
    0 = ROM sensors support application disabled. This option
    disables most of the registers in this section. There will not
    be any sampling process support. Only the host controller
    control registers may remain if ROMSupporteUSCIEnable is
    still set. See the beginning of this section for which registers
    remain.
    1 = ROM sensor support application enabled

    So, do digital sensors need to be supported by ROMSENSORSUPPORT when using I2C?
    Because mentioned above, There will not be any sampling process support.

    Best regards,

    Zhixiong CHEN

  • Hello Zhixiong,

    I'm not sure if this manual is matching to the Sensor Hub firmware.

    Anyway, I think the phrase "There will not be any sampling process support." refers to on chip ADC sampling.

    As far as I know the Sensor Hub Booster Pack board is doing the sampling of its equipped sensors and the RF430FRL152H is just reading the results via I2C. Thus I would assume that this should also work with a RF430FRL154H on the EVM board.

    I'm not expert enough to figure out any software incompatibilities, when reusing RF430FRL152H hex dump on a RF430FRL154H.

    Maybe you should try to re-compile your code with RF430FRL154H in the project settings.

    Btw: there is also an example project for RF430FRL154H in the default projects folder of the code examples (https://www.ti.com/lit/zip/slac691). Maybe you can figure out the relevant differences from that.

    Alternatively I can contact the software expert, after the vacation period is over.

    Best regards,

    Andreas.

  • Hi,

    I wonder if the code is not valid for 154H.
    When I use over-the-air programming, it prompts that a restart is required for the code to take effect : 

    After I restarted, the block0 of 152HEVM looks like this, and it works normally:

    154H is like this :

    It is more obvious that the status register (F869) is a read-only register, and in 154H I can change it at will.

    I think that some positions in the SENSORHUB program need to be modified so that it can support 154H, but I don’t know where to modify it.

    Best Regards,

    Zhixiong CHEN

  • Hi,

    I think it might be related to this.

    Best Regards,

    Zhixiong CHEN

  • Hello Zhixiong,
    chapter 8 in the Firmware User's Guide is referring to a feature of automatic FRAM initialization.
    For example an fresh manufactured RF430FRL15xH device contains 0xFFFF for all FRAM.
    On first boot-up the ROM will automatically initialize the FRAM, to be ready for NFC communication, so that over the air programming is possible.
    If your code image is overwriting the interrupt vectors, required for NFC communication, then you might lose NFC access
    This could be a reason for your unsuccessful memory read at 0xF868.
    The most flexible solution for code development would be direct code download via JTAG connector of the RF430FRL152HEVM board by using an MSP-FET programmer (https://www.ti.com/tool/MSP-FET?keyMatch=FET).
    This way you could also debug and single-step your new code.
    Best regards,
    Andreas.

  • Hi Andreas,

    I think the memory of F868 I read in 154H is reasonable. In fact, after 152HEVM completes over-the-air programming and before restarting, what I read in F868 is also FFFFFFFFFFFFFFFF. The NFC function of 154H is normal, I can modify the memory in these addresses. It just has not completed the initialization. As I said above, it needs to be restarted to work normally after the over-the-air programming is over. In 152HEVM, it should be controlled by address F8AE. The manual also mentions that the 154H does not have this function. I think this is the problem.

    Best Regards,

    Zhixiong

  • Hello Zhixiong,

    as said before, I'm not sure if the Sensor Hub example FW was ever intended to support the RF430FRL154H. Anyway the I2C should be available on this device, so you could create your own customized FW to control the Sensor Hub. The default FW project example for RF430FRL154, available in https://www.ti.com/lit/zip/slac691, could be a baseline for it.

    Best regards,

    Andreas.

  • Hi,

    I haven’t heard back from you for a while, so this tread is being closed. If you wish to continue the discussion, please post a reply with an update below (or create a new thread).

    Best Regards,
    Andreas.