• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2069 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.

MSP430G2201 Code Protection

Epic Vancouver
Intellectual 885 points

We are a little confused about how the MSP430G22x1 flash is password protected. I want to know how well our code is protected in this device.

 

1.       The datasheet mentions that the flash can be programmed by JTAG/SPY-BI_WIRE or in-system by the CPU (page 13 of the datasheet). Does in-system mean that the CPU can change flash as part of its’ programming or does it mean that the flash can be accessed externally?

2.       I understand that when the fuse is blown that JTAG functionality is lost but we can still fully access the flash with a password? Please confirm that the SPY-BI-WIRE interface also disabled when the fuse is blown. Does this simply melt the bond wire to the pin?

3.       According to the user guide the FCTLx is password protected but set to 096h to read and 0A5h to write. If the wrong value is entered then the flash is erased. Can this password be changed? If not, then why is this called a password when these values are public knowledge?

4.       There is mention in the MSP430 User’s Guide that the UART can be used to access the flash but I don’t think the MSP430G22x1 has a UART. Please confirm.

  • 0
    TI__Genius 17802 points

    Hi,

    1. In the firmware application the device/CPU can erase/write to flash via the flash controller. This is meant by "in-system" programming.

    2. When the electrical JTAG fuse is blown, both 4-wire JTAG and 2-wire JTAG (Spi-by-wire) interfaces are disabled. 

    3. The flash controller password is meant to prevent erroneous program code (lost control, program runs into the weeds, etc.) from mistakenly erasing/writing to flash. Only  code with intention to modify flash memory should provide proper flash password to unlock the controller. 

    4. I assume you mean a UART Boot Strap Loader (BSL) feature to update the device's firmware. If so, that is correct, the G22x1s do not have a built-in BSL. It does not have a hardware UART module either, but the UART functionality can be done in software utilizing the timer module. Please check the code examples package for this.

    Hope that answers all your questions!

     

    Dung 

  • 0
    Guru 12160 points

    Hi Eric,

    Most MSP430's have a TI bootstrap loader (BSL) that controls the device when first powered up (BOR).  Normally the BSL does some very basic device initialization and then hands control to your application in the reset handler.  However, if specific stimulus (publicly known) is applied to the device at the right time during device initialization, the BSL goes interactive instead of handing control to the reset handler.  Ultimately the interactive BSL gives complete flash access to the outside world via UART.  However, the user must first enter a private 256-bit password known only to you.  A single incorrect password causes the device to perform a mass erase.  Not too shabby.

    http://focus.ti.com/lit/ug/slau319a/slau319a.pdf

    However, if I understand correctly, the value line doesn't use an interactive BSL anyway.  That's even better than a 256-bit password!

    1.  In your case, flash can be accessed and programmed in system by the CPU only if you provide that feature in your application code.  Flash can also be accessed and programmed via JTAG/SBW until you blow the fuse.  Other MSP430's have the BSL that also allows flash access via the CPU as described above.

    2.  Yes the SBW interface is disabled permanently when you blow the fuse.  At that point the only flash access would be what your application code allows.  I don't know about the mechanical implementation of the fuse.

    3.  Yes if someone can manage to get code into your device, they can easily read, erase, or reprogram the flash.  Don't let anyone else put code into your devices.

    4.  As best I can tell, there is no interactive BSL on the MSP430G22x1, but even if there was it's pretty secure.  That would be the only UART access to flash aside from what your application code might provide.

    We have found that the MSP430 secures our code as well as any standard MCU can.

    Jeff

  • 0
    Guru 227245 points

    1. yes, the running program can change the flash itself at runtime. Usually, the flashing tool is injecting a small program and the data into MSP ram area and lets it execute from there. Then the program will do the erase of the flash and copy the chunk of data into flash. Then the next part is injected into RAM and the program will write it into RAM. The flash can be accesses externally through JTAG, but only a read operation makes sense, as the JTAG mechanism and the flash write mechanism are not really friends due to timing restrictions.

    2. blowing the fuse won't disbond the pin. It rather burns a fusible resistor inside the JTAG logic which permanently disables most of the JTAG electronic. It won't however, disable JTAG completely. Some JTAG functions (such as pass-through to chained devices) remain functional.On newer devices, this 'fuse' has been replaced by a connection between certain flash content and the JTAG logic. This was necessary to allow JTAG messaging (sending datagrams from and to the program) while disabling memory access. This way, the 'fuse' can be restored from within the main program, but not from outside.

    3. no. The FCTLx password protection (similar to some other password-protected modules such as Watchdog or power management) only server the purpose of preventing accidental writes. If an bit-changing instruction such as BIC (which does read-modify-write) or any other accidental write access is done to the FCTL register, the password won't match (as it is read differently from what you have to write) and will cause a device reset (as the program is obviously running wild). It has nothing to do with memory protection itself. It will just ensure that you won't accidentally program the flash controller registers and perhaps accidentally cause a mass erase or corrupt your program. Well, if this happens, your program seems to be buggy anyway :)

    4. Not exactly UART. Each MSP contains a built-in bootstrap loader. In most devices, this BSL implements a software UART on Port1 port pins which is RS232 9600bd compatible. If you follow the necessary entry sequence while the device is in reset state (usually connecting the reset and test pin with the RTS/DTR pins of a PCs COM port), the device will start the BSL rather than the program in flash. The BSL will then acept certain commands, including data read or write. Before you can read anything, you'll have to send a password which is stored in flash and part of the interrupt vector table. So you need to know what's currently in the MSP to unlock any read access to the MSP content. If you fail to provide the correct password, the BSL will do a mass erase and the MSP content is lost (and then the password is 0xFFFFFFFF as the flash is empty). So you can write the MSP using a serial connection, but only if you either know wat's in there already of face a mass erase prior to be granted access.
    Some MSPs have different BSL, so the 55xx devices with USB controller will support USB download instead of serial connection.

**Attention** This is a public forum