• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 486 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.

Original question:

MSP430F5438A: MSP-FET

MSP430F5438A: MSP-FET

Nadhir Aouinti
Prodigy 30 points

Part Number: MSP430F5438A

Hello,

Thank you @Brandon Fisher94 for your support , to set the electronic fuse for the MSP430F5438A mounted on a PCB (only JTAG accessible ) I have tried your suggestion by adding to the image file .txt : 

The programming phase finished but the verification phase failed due to a mismatch of  Values at address 0x017FC here an example of the batch file execution  : 

> dslite --mode flash -c user_files/configs/MSP430F5438A.ccxml -l user_files/settings/generated.ufsettings -s VerifyAfterProgramLoad="No verification" -e -f -v "user_files/images/3000487280-R72-000-02.txt"

DSLite version 11.0.0.2538
Configuring Debugger (may take a few minutes on first launch)...
Initializing Register Database...
Initializing: MSP430
Executing Startup Scripts: MSP430
Connecting...
Loading Program: user_files/images/3000487280-R72-000-02.txt
Preparing ...
0 of 2048 at 0x1000
0 of 58 at 0x5c06
0 of 261736 at 0x5d98
32752 of 261736 at 0x5d98: 13%
65504 of 261736 at 0x5d98: 25%
98256 of 261736 at 0x5d98: 37%
131008 of 261736 at 0x5d98: 50%
163760 of 261736 at 0x5d98: 62%
196512 of 261736 at 0x5d98: 75%
229264 of 261736 at 0x5d98: 87%
0 of 344 at 0x5c40: 99%
0 of 2 at 0x182: 99%
0 of 4 at 0x17fc: 99%
Finished: 99%
Setting PC to entry point.: 99%
info: MSP430: There were 264192 bytes written.
Verifying Program: user_files/images/3000487280-R72-000-02.txt
Preparing ...
0 of 2048 at 0x1000
error: MSP430: File Loader: Verification failed: Values at address 0x017FC do not match Please verify target memory and memory map.
Finished

But after trying to program again the device is no longer accessible and it has been secured  here an example : 

> dslite --mode flash -c user_files/configs/MSP430F5438A.ccxml -l user_files/settings/generated.ufsettings -s VerifyAfterProgramLoad="No verification" -e -f -v "user_files/images/3000487280-R72-000-02.txt"

DSLite version 11.0.0.2538
Configuring Debugger (may take a few minutes on first launch)...
Initializing Register Database...
Initializing: MSP430
Executing Startup Scripts: MSP430
Connecting...
error: MSP430: Error connecting to the target: The Debug Interface to the device has been secured

Should I disable verification after flashing and if so does that affect the program execution afterwards 

Best Regards,

Nadhir Aouinti

  • 0
    TI__Mastermind 28235 points

    Hi Nadhir,

    Disabling the verification is fine, it shouldn't affect the operation of your application assuming everything was loaded correctly. I don't necessarily think the verification should be failing, and it appears to be failing right at the beginning of verification in BSL memory, which makes sense given what we modified. Given that we changed the ti-txt file manually to lock the JTAG, it could be that it expects that memory to be blank during that first scan. 

    Does your application seem to be running okay? Are you writing anything else to BSL memory in your code, and what do your Erase settings look like? 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 30 points

    Hi Brandon,

    Thank you for your response,

    I've disabled the verification and the application works fine and the device is secured  , I don't have access to the software I' am only programming using TI.txt image 

    the BSL memory is not used in the image : 

    and my Erase settings are in the generated.ufsettings : 

    {"TI MSP430 USB1/MSP430":{"MSP430UnlockBSLMode":true,"MSP430DownloadOptions":"Erase main, information and protected information memory"}}

    and in the dlite.bat are : 

    set GENERATED_COMMAND=-c user_files/configs/MSP430F5438A.ccxml -l user_files/settings/generated.ufsettings -s VerifyAfterProgramLoad="No verification" -e -f "user_files/images/3000487280-R72-000-02.txt"
    set ADDITIONALS=

    Best Regards,

    Nadhir Aouinti

  • +1 in reply to Nadhir Aouinti
    Prodigy 30 points

    Hi Brandon,

    excuse me but  the orginal ti.txt file contains : 

    @17FC
    FF FF FF FF

    that is why verification was failing 

    but it does not contain the unlocking of BSL MEMORY  at  @0182

    Note : 

    after reading the document  SLAU208Q (MSP430x5xxandMSP430x6xxFamily User'sGuide) page 73  "1.11.2 JTAG Lock Mechanism Using the Electronic

    Fuse" 

     and the document SLAU320AJ (User’s Guide MSP430Tm Programming With the JTAG Interface) page 52 "2.4.2 Programming the JTAG Lock Key -

    Function Reference for 5xx, 6xx, and FRxx Families 2.4.2.1 Flash Memory Devices  

    and referencing to SLAU208Q page 88  (SYS Registers table ) ==>

    and finally page 90 (SYSBSLC Register "Bootloader Configuration Register") : 

    I undrestand why you used those values for those adresses  but  i don't undrestand the difference between setting  the bit SYSBSLOFF to 0b or to1b

    and what is the difference between boot code and BSL in MSP430  ? is that similar to  bootloader and IAP in STM32 architecture ?

    Best Regards,

    Nadhir Aouinti

  • +1 in reply to Nadhir Aouinti
    TI__Mastermind 28235 points

    Hi Nadhir

    Nadhir Aouinti said:

    I undrestand why you used those values for those adresses  but  i don't undrestand the difference between setting  the bit SYSBSLOFF to 0b or to1b

    So if you set the SYSBSLOFF bit to 1,  then an access to BSL memory is going to be treated like a vacant memory access. It will generate an NMI if VMAIE is enabled. 

    If you set SYSBSLOFF to 0, then you can attempt to read or write to the BSL memory, and it will not be treated as a vacant memory access. Meaning no NMI is generated. There may be times when you want attempts to access BSL memory to be treated like a vacant memory access, and there may be times when you do not. 

    Just having SYSBSLPE set is enough to protect this memory in general, and it's what the MSP430F5x boot code does by default. 

    Nadhir Aouinti said:

    and what is the difference between boot code and BSL in MSP430  ? is that similar to  bootloader and IAP in STM32 architecture ?

    I am not familiar with IAP in STM32, but the Boot Code is just default code run on startup in MSP430, which checks for the correct bootloader to run (including setting that SYSBSLPE bit if desired) and does some other housekeeping like loading calibration values. 

    The BSL code is actually run when your BSL invocation conditions are met, and manages how you to actually write to flash memory on the device via some alternative interface like I2C, USB, or UART.

    Best Regards,
    Brandon Fisher

**Attention** This is a public forum