• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 78 subscribers
  • Views 437 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5335: MSPFlasher Exit: 10 Could not reset device

Greg Dunn
Intellectual 475 points
Part Number: MSP430F5335
Other Parts Discussed in Thread: UNIFLASH

Hello,

We have been using the MSPFlasher (v1.3.20 currently) utility to load firmware on several of our MSP430F5335 based products for quite a while now in our standard production process. We have been loading a custom BSL image as well as the normal application image with no issues. I created a batch file for this process to make it easier for our production team. I was making two calls to MSPFlasher, one to program the custom BSL and one for the application. Recently I updated the BSL to use the JTag lockout feature to keep JTag access disabled by default when the product is deployed in the field. The updated BSL allows for enabling the JTag on boot up if a certain GPIO is grounded during reset. This change is requiring our production staff to ground the GPIO line in order to allow the standard batch file to successfully program the part, even with a brand new part which has the default factory BSL.

If possible, I would like to allow our production staff to do the initial programming (factory BSL in part) without requiring the GPIO line to be shorted to ground. In an attempt to accomplish this, I have tried several approaches (unsuccessfully):

1) I have tried adjusting the command line options with MSPFlasher to not reset the device after programming the custom BSL so that I can make a second MSPFlasher call to continue programming the application and then do the reset when complete. This was done with two calls to MSPFlasher and it didn't seem to work.

2) If have tried programming the application code first and then programming the BSL. I used the ERASE_SEGMENT option with -e to try and allow the BSL programming process on only erase the memory areas required for the BSL, but the BSL code apparently crosses segment boundaries, and I got an error.

3) As a third attempt, I tried combining the custom BSL and application code into one intel hex file so I could program everything in one call to MSPFlasher, but it still didn't seem to work unless I grounded the GPIO line.

Here are the results of option 3 above with the GPIO line NOT GROUNDED:

D:\XA32>tools\MSPFlasher\MSP430Flasher.exe -w "E3_MSP.hex" -v -b -s -z [RESET,VCC=3300]
* -----/|-------------------------------------------------------------------- *
* / |__ *
* /_ / MSP Flasher v1.3.20 *
* | / *
* -----|/-------------------------------------------------------------------- *
*
* Evaluating triggers...done
* Checking for available FET debuggers:
* Found USB FET @ COM7 <- Selected
* Initializing interface @ COM7...done
* Checking firmware compatibility:
* FET firmware is up to date.
* Reading FW version...done
* Setting VCC to 3300 mV...done
* Accessing device...done
* Reading device information...done
* Unlocking BSL memory...done
* Loading file into device...done
* Verifying memory (E3_MSP.hex)...
# Exit: 10
# ERROR: Could not reset device
* Resetting device (RST/NMI)...done
* Starting target code execution...done
* Disconnecting from device...done
*
* ----------------------------------------------------------------------------
* Driver : closed (EEM polling thread is already active)
* ----------------------------------------------------------------------------

*/

The application does not automatically start when MSPFlasher exits. If I cycle the power on the board after the above attempt, the board will boot up properly and appears to have programmed the BSL and application successfully.

Here are the results of option 3 above with the GPIO line grounded:

D:\XA32>tools\MSPFlasher\MSP430Flasher.exe -w "E3_MSP.hex" -v -b -s -z [RESET,VCC=3300]
* -----/|-------------------------------------------------------------------- *
* / |__ *
* /_ / MSP Flasher v1.3.20 *
* | / *
* -----|/-------------------------------------------------------------------- *
*
* Evaluating triggers...done
* Checking for available FET debuggers:
* Found USB FET @ COM7 <- Selected
* Initializing interface @ COM7...done
* Checking firmware compatibility:
* FET firmware is up to date.
* Reading FW version...done
* Setting VCC to 3300 mV...done
* Accessing device...done
* Reading device information...done
* Unlocking BSL memory...done
* Loading file into device...done
* Verifying memory (E3_MSP.hex)...done
*
* ----------------------------------------------------------------------------
* Arguments : -w E3_MSP.hex -v -b -s -z [RESET,VCC=3300]
* ----------------------------------------------------------------------------
* Driver : loaded
* Dll Version : 31400000
* FwVersion : 31200000
* Interface : TIUSB
* HwVersion : U 3.0
* JTAG Mode : AUTO
* Device : MSP430F5335
* EEM : Level 7, ClockCntrl 2
* Erase Mode : ERASE_ALL
* Prog.File : E3_MSP.hex
* Verified : TRUE
* BSL Unlock : TRUE
* InfoA Access: FALSE
* VCC ON : 3300 mV
* ----------------------------------------------------------------------------
* Resetting device (RST/NMI)...done
* Starting target code execution...done
* Disconnecting from device...done
*
* ----------------------------------------------------------------------------
* Driver : closed (No error)
* ----------------------------------------------------------------------------
*/

I get no errors with the GPIO line grounded, and the application automatically starts running when MSPFlasher exits.


Do you have any suggestions of how I may be able to do this. I would like to minimize our production steps by not requiring that they ground the GPIO line when programming a new part from TI. I understand and want all future JTag access to require grounding the GPIO line.

Thanks,
Greg Dunn

  • 0
    TI__Mastermind 38410 points

    1. It seems that you want to reporgarm your device again with your customized BSL, right?

    2. Why you can't accept the GPIO conncted to GND? Can you add a communication command in the BSL to enable JTAG?

  • 0 in reply to Eason Zhou
    Intellectual 475 points

    In this case, I am not RE-programming the BSL.  I am trying to create a process for our production department to program the device for the first time.  In this case, the default factory BSL would still be in the device.  We can just ground the GPIO line if necessary, but it just adds an extra step during production that I thought we may be able to eliminate since the factory default BSL was still in the device initially.  I am not sure that I undestand exactly what you mean by adding a communication command in the BSL to enable JTAG.  Is there something we could add that would allow the MSPFlasher to communicate to the BSL?

    For some more information:  Our custom BSL monitors a GPIO line and as long as it is high on bootup, the JTAG is locked.  If the GPIO is low on bootup then the JTAG is left open.  It seems like the MSPFlasher is trying to issue a reset after the verify step.  The custom BSL has been loaded at this point and is most likely causing the issue since the JTAG would be locked if the GPIO is high (not connected).  Is there no way to defer the reset to the very end of the process or is a reset necessary after the verify step.  This may already be the last step of the process, but MPSFlasher is trying to verify that the application is running somehow over JTAG.  I have not studied exactly how MSPFlasher works at the end of the process. 

    What I am wanting may not be possible.  I was just wanting to eliminate the need to ground the GPIO if we could get around it during intial production only.  I understand that it will have to be grounded for any updates to our custom BSL.

    Thanks,

    Greg Dunn

  • 0 in reply to Greg Dunn
    TI__Mastermind 38410 points

    If you want to unlock the device through JTAG, it is impossible.

    The only solution to unlock JTAG is through:

    • 1. Through factory BSL
    • 2. Through software (Like your GPIO setting)

    What I mean is that you can send some commend to unlock the devices through UART port. I assume you need to generate a new PC software and update your BSL.

  • 0 in reply to Eason Zhou
    Intellectual 475 points

    I am not really trying to unlock the JTAG.  This is a brand new part with the factory BSL initially.  The JTAG is already unlocked by default.  The MSPFlasher program is connecting just fine, programming the firmware, and attempting to verify.  The issue seems to be that MSPFlasher is failing to reset the part at the end of the verify process and does not actually indicate whether the verify was successful or not, only that the reset failed.  If you cycle the power on the part, it will boot up properly and custom BSL and application seem to have been programmed successfully.  There is just no indication to the user that the verification was truly successful.  It just seems like there would be a way to do all of the programming on a fresh part (factor BSL), do the verify and output verify status only, and then at the end of the entire process reset the device.  We could live with the reset failing if we know that the image was actually verified in the device.

  • 0 in reply to Greg Dunn
    TI__Mastermind 38410 points

    It seems that the the MSPFlasher doesn't reset the deivce properly though JTAG. Then you can't do the function test.

    The another solution would be do the CRC check to help you know the program is right? However, the CRC will not report the result in some condictions right? When will this problem happens?

    * Verifying memory (E3_MSP.hex)...
    # Exit: 10
    # ERROR: Could not reset device
    * Resetting device (RST/NMI)...done
    * Starting target code execution...done
    * Disconnecting from device...done

  • 0 in reply to Eason Zhou
    Intellectual 475 points

    I'm not really sure that I fully understand your questions but I'll attempt to answer.

    I am getting the error results you showed when I use my original option 3 in my first post where I combine the custom BSL and application into one intel hex file and try to program both together in one call to MSPFlasher with the following command line to a chip with the default factory BSL.  

    D:\XA32>tools\MSPFlasher\MSP430Flasher.exe -w "E3_MSP.hex" -v -b -s -z [RESET,VCC=3300]

    The error only occurs if the GPIO line left open where the custom BSL will keep the JTAG closed.  If I ground the GPIO line then everything is successful.

    At this point, unless you have some suggestions, I think we will just give up and just include grounding the GPIO line in our process.  It is not that big of a problem, I was just trying to keep things as simple for them as possible.

  • 0 in reply to Greg Dunn
    TI__Mastermind 38410 points

    Sorry, too much information get from you.

    I think you problem is that when you program the devices with your customized BSL with GPIO open. The MSPFlasher will can't reset the device successfully.

    I think the reason is that:

    1. The MSPFlasher do the CRC/RESET(reset can be done through JTAG or hardware) through JTAG

    2. After programming, it will let the MCU run for a little time

    3. As your customzied BSL lock the JTAG, the MSPFlasher will can't do CRC/RESET through JTAG.

    I would suggest you to use Uniflash to make a try. It may can solve your problem.

  • 0 in reply to Eason Zhou
    Intellectual 475 points

    Thank you.  I will try Uniflash and see if it works differently.

**Attention** This is a public forum