• State
  • Locked Locked
  • Replies 23 replies
  • Subscribers 80 subscribers
  • Views 12184 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.

MSP430FR5738: Reset of Entry Address through MSPFLASHER Read

David Bahr
Prodigy 120 points
Part Number: MSP430FR5738
Other Parts Discussed in Thread: MSP430FR5739, MSP-GANG, MSP-EXP430FR5739, MSP-EXP430F5529LP, MSP-EXP430FR6989, MSP-EXP430FR2311, MSP-EXP430FR4133, MSP-FET, MSP-EXP430FR5969, MSP-EXP430FR5994, , MSP-FLASHER, MSP430-FLASHER

Hi,

It happens from time to time that when I create a complete Firmware Image by using the -r command of the MSP430Flasher.exe the Code Entry Address is reset to 0xFFFF.

command:

C:\ti\MSPFlasher_1.3.11\MSP430Flasher.exe -r [example_readout.hex , MAIN] -j "slow" -z [RESET,VCC=3000]

example of corrupted entry address in hex file

...

:20FFE00004FD04FD04FDFFFF04FDC2FB04FD12D004FD04FD04FDC0FC04FD04FD04FDFFFF9F

...

example of correct entry address in hex file

:20FFE00004FD04FD04FDFFFF04FDC2FB04FD12D004FD04FD04FDC0FC04FD04FD04FD24FC7D
:00000001FF

I would be happy If someone could give me any Ideas of how this might happen and how to prevent. 

b.r.

David

  • 0
    TI__Guru* 79401 points
    Hi David,

    Thanks for posting - I'll work to help figure out your issue. It looks like the reset vector at address 0xFFFE is being erased. I see that you are using the MSP430FR5739 device - can you comment on whether the code that you currently have loaded in the device contains any code that can modify FRAM? E.g., do you have a custom bootloader program loaded in the main FRAM? The reason I am asking is because a lot of custom bootloader programs may program in the reset vector very last of all so that the device will not run the code, then the reset vector is only written once all other code has been written in. Alternately, if any application code that can modify FRAM is able to run after the reset, and the MPU is not enabled in the application, then the value could also potentially be erroneously modified by application code.

    Had the device showing FFFF been previously verified after the last load to have had 24FC correctly in it? Or had it maybe been loaded since then? How is code being loaded?

    Regards,
    Katie
  • 0 in reply to Katie Pier
    TI__Guru* 79401 points
    Hi David,

    Any update? I would like to help figure out why you are seeing this behavior.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 120 points
    Hi,

    Thank you for your reply... I was out of office a few days.
    The code contains parts that modify the FRAM, but not the reset vector.

    I am using MSPFLASHER to create a complete Firmware image at the end of our Production processes.

    Before creating an image the Firmware is loaded and tested for a few minutes --> So before creating the image the 24FC was correct inside the FRAM.

    May the MSPFLASHER write to the reset vector at the beginning of a read?

    b.r.

    David
  • 0 in reply to David Bahr
    Prodigy 120 points
    Hi Katie,

    Any Idea what else I can check?
    Is there an other Forum where I might ask about the MSPFLASHER?

    b.r.

    David
  • 0 in reply to David Bahr
    TI__Guru* 79401 points
    Hi David,

    Sorry for the long delay - I am still working with our tools team who write MSP430Flasher on this, but some people have been out of office. I will try to push for more details and ideas on why this could be happening.

    -Katie
  • 0 in reply to Katie Pier
    TI__Guru* 79401 points

    Hi David,

    I can confirm with the team that writes MSP Flasher, that MSP Flasher does not write into FRAM nor the reset vector as any part of its memory read flow. Have you tried any other tool like Elprotronic Fet-Pro430 or CCS or MSP-GANG and been able to observe the same behavior?

    If you create a test version of your code that you load into the part, that does not do any FRAM writes at all, can you reproduce the behavior anymore? I know your firmware should not write to the reset vector, but the concern would be what if the firmware is acting unexpectedly if it is allowed to run for a brief time during the MSP Flasher read operation (sometimes firmware can execute for short intervals during JTAG access).

    Does your firmware enable the MPU for protecting the FRAM areas that you don't want to be modified, including the reset vector? If so, are you using the MPU tool in CCS or doing it manually in your code (and please include that part of the code so we can see the MPU settings)?

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 120 points
    Hi Katie,

    Thank you for your investigation.

    I will try out with a firmware that does not hold any fram writes.

    But also I have some brand new findings by using mspflasher:

    Failing:
    1. Jtag Enable and ResetL are not connected to the Target.
    2. I do a read with mspflasher --> fails because no target is connected.
    3. I connect the target (JtagEnable and ResetL)
    4. I do a read with mspflasher --> vector address is reset to 0xFFFF

    not failing:
    1. Jtag Enable and ResetL are not connected to the Target.
    2. I do a read with mspflasher --> fails because no target is connected.
    3. I unplug the programmer from usb
    4. I reconnect the programmer to usb
    5. I connect the target (JtagEnable and ResetL)
    6. I do a read with mspflasher --> vector address stays correct!

    so it looks like the programming adapter or the mspflasher somehow keeps in memory that there was a failing read and next time I do a read it resets the vector address!

    Do you have any Idea for a workaround for that?

    best regards,

    David
  • 0 in reply to David Bahr
    Prodigy 120 points

    Hi,

    I have now tested with firmware that is not writing to FRAM and the result is equal.

    mspFlasher has the DLL Version : 20409001

    I am using the MSP-EXP430FR5739 Board as a programmer:

    FwVersion : 30328680

    with this combination i see the described behavior.

    But if I use the older launchpad board MSP-EXP430G2 (FW: 20066536) as programmer, everything goes as it should.

     

    Since I have several MSP-EXP430FR5739 baords in production used as programmer, is there any chance for you to figure out  if it is Firmware related and how I can force to load a specific Firmware?

     

    best regards,

     

    DAvid

     

     

     

     

     

     

  • 0 in reply to David Bahr
    TI__Guru* 79401 points

    Hi David,

    Thanks for the additional information, and doing the tests to rule out code being able to do the FRAM write. Knowing more about the hardware and firmware versions involved (thank you!), I'll try to work with our tools team to reproduce the issue so we can find root cause and determine what hardware/firmware versions will be unaffected.

    Regards,
    Katie

  • 0 in reply to Katie Pier
    Prodigy 120 points

    Hi Katie,

    Do you have any update? This is really urgent for me.

    best regards,

    David

  • 0 in reply to David Bahr
    TI__Guru* 79401 points

    Hi David,

    Apologies for the delay - I've been out of office most of the week.

    To try to further understand the issue, I've been asked if the same thing occurs on newer programmers (e.g. eZ-FET or MSP-FET). If you have any MSP430 Launchpad besides the MSP-EXP430G2 or the MSP-EXP430FR5739 experimenter board, it will have some variant of eZ-FET (instead of the legacy eZ-430 on the two boards you have). So, MSP-EXP430F5529LP, MSP-EXP430FR5969, MSP-EXP430FR6989, MSP-EXP430FR5994, MSP-EXP430FR4133, MSP-EXP430FR2311 would all be ones that would help test this, if you have access to any of them. Is this something you have access to?

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 120 points

    Hi,

    Unfortunately I do not have any other eval boards.

    best Regards,

    David

  • 0 in reply to David Bahr
    TI__Guru* 79401 points
    Hi David,

    Sorry to hear that. I have someone on my team working to reproduce the issue on the MSP-EXP430FR5739 following the steps in your previous post, then if we can make that fail reliably we can try the other boards.

    If there's anything else you think would help us to reproduce your failing setup just let us know, but the plan is to use the same version of MSP430Flasher that you mentioned, the MSP-EXP430FR5739 board with its built-in eZ430, and just try to program the part with some basic software and then repeatedly read it. Any other tips to make it reliably fail or better match your setup? You are just letting the board be powered from the built-in USB right?

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 120 points

    Hi,

    Yes I only use the usb to power the board. 

    Use the MSP-EXP430FR5739 only as a programmer. The TEST, RST and GND are connected to the MSP430FR5738 that is placed on our product. 

    I was now able to find an other MSP-EXP430FR5739 board that has a different firmware that is not failing!

    correct working combination:

    board: MSP-EXP430FR5739 Rev.1.1

    Arguments   : -n MSP430FR5738 -r [readout.txt, main]

    * Dll Version : 20409001
    * FwVersion : 30394216

    code entry destroying combination:

    board: MSP-EXP430FR5739 Rev.1.1

    Arguments   : -n MSP430FR5738 -r [readout.txt, main]

    * Dll Version : 20409001
    * FwVersion : 30328680

    hope this helps you for your investigation. 

    Is it possible for me to load the "FwVersion : 30394216" to all my MSP-EXP430FR5739 boards?

    best regards,

    David

  • 0 in reply to David Bahr
    TI__Intellectual 1370 points

    Hi David,

    I contacted our tools team to see if you would be able to update the firmware on your MSP-EXP430FR5739 board, and I will pass along the information once they get back to me.

    I was able to track down two MSP-EXP430FR5739 boards with firmware version 30328680 and have begun testing to see if I can reproduce the problem you are experiencing. I have attempted to program the MCU from one board using the debugger on the other board with TEST, RST, and GND connected through jumper wires attached to the header pins. So far I have not been able to replicate the results.

    How frequently would you say this problem occurs when you program the MSP430FR5738 device and read back the memory? Does this problem still occur if you reattach the TEST, RST, and GND header jumpers back onto the MSP-EXP430FR5739 and program the MSP430FR5379 on the Experimenter Board directly? How are you connecting the TEST, RST, and GND signals from the MSP-EXP430FR5739 to your product board?

    Sincerely,

    Ryan

     

  • 0 in reply to Ryan Meredith
    Prodigy 120 points

    Hi Ryan,

    Thank you for testing this.

    This issue is 100% reproducible. It occurs in 100% of the trials.

    You can even just user the MSP430FR5739 that is on the same MSP-EXP430FR5739 board.

    Procedure:

    1. load Firmware to the MSP-430FR5739

    for example ti-format-txt file:

    @FFFE
    50 FE
    q

    2. Disconnect the TEST Jumper

    3. make a read:msp430flasher.exe -n msp430fr5739 -r [readout.txt, main]  --> this will fail because TEST is not connected

    4. Connect the Test Jumper

    5. make a read:msp430flasher.exe -n msp430fr5739 -r [readout.txt, main]  

    6. check the the readout.txt --> Address 0xFFFE will be set to FFFF!

    If you disconnect and reconnect the usb-cable between 4. and 5. the code entry address won't be deleted!

    best regards,

    David

  • 0 in reply to David Bahr
    TI__Guru* 79401 points
    Hi David,

    Thanks - I did exactly this sequence with MSP-EXP430FR5739 and I was able to reproduce the issue. I have to have the failed read in order for the erasure to happen. Hard to know if the erase is happening on the failed read or on the next read after that though.

    I can also reproduce if I remove just RST instead of TEST, with the same sequence. However, if I remove both RST and TEST, I cannot reproduce. This makes me suspect that all of this is related to the entry sequence performed on the RST and TEST pins. For some reason if an access is attempted with one of the pins connected (so an entry sequence is performed but only one of the lines is present, rather than getting the real entry sequence) you see this reset vector clearing behavior. This is likely due to the additional edges on this line causing the state machine for the entry sequence to go into a different/unexpected state. A power cycle prevents the erase from happening as well (even if I just pull the Vcc line, not disconnect the USB totally) which also supports this theory.

    I will work with our team that creates the MSP-FLASHER tool to determine why this erroneous entry sequence would lead to the reset vector being cleared though, as that piece is something I don't yet understand. I will keep you posted.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 120 points
    Thank you,

    Just a quick reply that might help:

    the erase is definitely happening on the next read after the failed read! Because if I do a failed read and then unplug the usb cable and reconnect it, the next read is good and Address 0xFFFE is not set to 0xFFFF.

    hope this helps.

    best regards,

    David
  • 0 in reply to David Bahr
    TI__Guru* 79401 points

    That is right.

    I have now also tested our newer tools: MSP-FET, and the eZ-FET included on all of our newer launchpads as I listed in my earlier post. These are not affected by the issue. If you need something to get yourself up and running in the meantime while we continue to investigate root cause, you may want to try to obtain one of these.  

    As a question, is your concern primarily for production programming, or for your own development? The eZ-430 on the MSP-EXP430FR5739 is intended for use as a development tool, not as a production programmer. For production programmers we would recommend the MSP-FET or MSP-GANG. These have the added benefit of also programming the part faster to save production time.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 120 points
    Hi,

    Production Time is not the primary focus. How much faster would a MSP-FET be by programming a 16kbit Firmware compared to the MSP-EXP430FR5739?

    I have these boards already fixed in production and on short-term only a firmware fix would be a solution for me.

    BTW: my MSP-EXP430FR5739 is showing the "wrong" behavior when RST or TEST are disconnected but also if both are disconnected.
    The "wrong" behavior is also shown when both lines are connected but the targed MCU is not powered with VCC.



    best regards,

    David
  • 0 in reply to David Bahr
    TI__Guru* 79401 points
    Hi David,

    You can find benchmarking info for MSP-FET and MSP-GANG in the debugger user's guide www.ti.com/lit/pdf/slau278 and the MSP-GANG user's guide www.ti.com/lit/pdf/slau358. In some quick bench tests that I ran the FR5739 programmed a full 15.5kB image at least 30% faster with MSP-FET than the eZ430. MSP-GANG at top speed was even faster than MSP-FET.

    But programming speed is not the only reason. As mentioned, the eZ430 programmer on the MSP-EXP430FR5739 is not intended as a production programmer. It is not capable of firmware updates, so there is no way to maintain it over time with updates for new devices, new features, or bug fixes. Our production programmers are capable of firmware updates and are regularly maintained with the latest improvements. This is why I would further recommend moving to MSP-FET or MSP-GANG. eZ-FET is also not technically a production programmer but at least it is capable of firmware updates so it is also actively maintained so would also at least be a better option for you to be able to move forward.

    To go back to your issue at hand: the only way to reproduce the issue is by disconnecting RST/TEST lines, doing some failed reads, and not power cycling the device. Normally, in a production setting this should never happen. Going back to your setup, you mentioned that this would happen occasionally - are devices having connections plugged/unplugged while powered (hot-plugging?) Even if you aren't doing that, perhaps some of your programmer connections might be marginal, since you must be using some sort of custom cable or pins to go from the eZ430 to the device you are programming? These are the only ways I can think of that this type of situation could happen intermittently. Whether you switch programmers or not, you probably will want to look further into the overall programming setup to identify if erroneous edges on the programming lines could be occurring.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 120 points

    Hi Katie,

    The MSPFlasher user guide says that firmware can be updated (" Update FET firmware (if a mismatch between firmware and MSP Debug Stack versions is detected) ").

    Would it be possible to force a firmware update/downgrade to:

    * Dll Version : 20409001
    * FwVersion : 30394216

    I can not go into detail about the way I connect the Target, since this is an open forum. 

    Since I figured out the root cause for deleting the Code Entry Address, I have already implemented additional precautions.

    But Currently my only way to check if there is a proper connection between the MSP-EXP430FR5739 and the MSP430FR5738 is to make a read via mspflasher.exe.

    If this read would fail, I would have to reset the MSP-EXP430FR5739 somehow to prevent deleting the Code Entry Address of the Next MSP430FR5738.

    Do you have any Idea how I can make the MSP-EXP430FR5739 to forget that there was a failing read?Or how I can reset it without unplugging the usb?

    This would be a sufficient workaround for me. And for long-term and future products, I will think about using factory programmers.

    best regards,

    David

  • 0 in reply to David Bahr
    TI__Guru* 79401 points
    Hi David,

    The eZ430 is not updateable - that has always been a limitation of the legacy eZ430 hardware. Additionally the eZ430 can only support the device for the board it came with, and it can't be updated to support any new devices. The eZ-FET is the replacement for the legacy eZ430. The MSP430-Flasher can update the firmware on MSP-FET and eZ-FET, which support all MSP430 devices. There is no recommended way to force a firmware update/downgrade on the eZ430. Therefore it would be recommended to use eZ-FET or MSP-FET so that you can be able to keep up with firmware updates, new devices, bug-fixes, etc. See the MSP Debugger's Guide www.ti.com/lit/pdf/slau647 for more information on different debuggers.

    Regards,
    Katie

**Attention** This is a public forum