• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 18 subscribers
  • Views 1319 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: RESET vector overwrite issue

Alberto Soattin
Genius 16905 points

Part Number: RF430FRL152H

Hi Support,

my customer is facing issues with the RESET vector of RF430 part. 

In particular, sometimes the firmware of the MCU is corrupted during reading of the application values via RFID.

It doesn’t help restart the module (take it out from the RFID field and put it again there). They have to upload the firmware again to start the communication again.

The modules are prototypes. They know that the firmware is possible to upload via RFID and maybe this can be source of the problem.

Their question is whether they could somehow lock the firmware update via RFID. 

More details coming directly from customer after tests:

Today I tested the corruption of the firmware again and I have a new detail information about the problem.

The problem is still the same the RESET vector is somehow overwritten.

So I tried to lock the memory by using FRAMAaccessLimitRegister.

I have written to this register value 0xFFD0 to lock end of the FRAM memory from address 0xFFD0 to the end of the memory area. I did this by declaration in linker command file:

FRAMACCESSLIMITREGISTER : origin = 0xF864, length = 0x0002, fill = 0xFFD0

After programming the code to the device I verified that the value on the address 0xF864 is 0xFFD0 via debugger.

After some time I paused the code and checked again this FRAMAaccessLimitRegister. But the value on the address 0xF864 changed to 0xFFFF (memory lock was somehow damaged). The RESET vector in this point was still correct. Then I unpaused the code and left the device running.

After about 5 minutes the device was not answering to the RFID reader. So I checked the RESET vector. The RESET vector was changed from value 0xFD18 to 0xFF18.

I do not have any idea why is this happening.

 

Do you have any idea what can be source of the problem?

Firmware bug?

RAM overflow?

What else?

 

Thanks,

Regards,

Alberto

 

  • 0
    TI__Guru*** 135355 points
    Hello Alberto,

    "Their question is whether they could somehow lock the firmware update via RFID."
    - It is possible to place a JTAG lock, but I am not sure this is what they meant. I don't think that would help in this situation.
    - Is there a different kind of locking they meant, maybe I am unclear on this question.

    Aside from RF communication overwriting areas such as a the RESET Vector, it may be possible code overflow could affect that as well? I don't think we have seen that before, but depending how their firmware is setup that could be a possibility, and one I certainly don't want to rule out at this stage.

    Can they try and replicate this issue on the RF430FRL152HEVM as well? It seems to be a firmware issue so I feel this should be possible. That would let me re-create the issue with my own hardware...
  • 0 in reply to Ralph Jacobi
    Prodigy 20 points

    Hello Ralph,

    I tried to replicate the issue on the RF430FRL152HEVM, but I was not successful.

    The same firmware works well on RF430FRL152HEVM. 

    We have 3 pcs of temperature sensor tag designed by us. Two of them are failing (RESET vector overwriting) and one of them is working well from the beginning.

    Is there something critical in hardware design what can cause such a problem?

  • 0 in reply to Roman Malachovsky
    TI__Guru*** 135355 points
    Hello Roman,

    As I alluded to before, this is the first time I've heard of this specific issue, so I certainly wouldn't want to rule out hardware out if the issue is not repeatable on the RF430FRL152HEVM but it's too early to say one way or another.

    I definitely would like to review your application schematic.

    Furthermore, since it isn't clear yet what the root cause is, can you swap one of the chips which exhibit the issue from your sensor tag design onto the RF430FRL152HEVM and see if the issue goes away on the EVM?

    Then you can also try and put the chip from the EVM and place that on your sensor tag?

    This would be a good test to try and isolate whether the issue follows the hardware board or the actual IC.
  • 0 in reply to Ralph Jacobi
    Prodigy 20 points

    Hello Ralph,

    I have found probably the source of the problem. I double checked our schematic and found some differences.

    The capacitor on VDDSW pin and VDDD pin we had only 100nF. The recommended value in the datasheet is 2.2uF for VDDSW pin and 1uF for VDDD pin.

    So I have changed the capacitors and the RFID sensor tag is now working without any problem. For sure I will test it for longer time.

    In the meantime could you confirm me please that the small value of the capacitors (100nF on VDDSW pin and VDDD pin) could have such a effect on RESET vector or FRAM memory?

  • 0 in reply to Roman Malachovsky
    TI__Guru*** 135355 points

    Hello Roman,

    For VDDD, 100nF will be fine too. Actually if you look at the main schematic and recommended values in that section, 100nF is what is used for VDDD (listed as VDD on the schematic portion of the datasheet).

    For VDDSW, the 2.2uF value is crucial as it a decoupling cap for internal regulators. I think the effect you were seeing is more of an effect on FRAM memory than the RESET vector itself. In any event, it definitely would cause the IC to have issues because the internal regulators would not be functioning correctly with such a small cap value on them.