Hi Tom, Thanks for the feedback, and thanks for providing some more information about your situation. First, I wanted to point out that the version of the documentation that you are referencing, “Features of the MSP430 Booststrap Loader (BSL)” www.ti.com/lit/pdf/slaa089 rev. A is very out-of-date (last version was rev F) – I’d recommend referencing “MSP430 Programming Via the Bootstrap Loader” www.ti.com/lit/pdf/slau319 which has actually superseded it, to get the most up-to-date information. There is also a zip file that goes with it: http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPBSL_Scripter/latest/index_FDS.html The Deprecated folder inside that download includes BSLDEMO software, which is a PC host for the BSL on the older 1xx/2xx/4xx parts (source code is included). For all newer parts, it includes the BSL scripter, which supports F5xx/6xx, all FRAM, and MSP432 devices. I think that for your use-case with the MSP430F169 , the best option for you is going to be this: Set your project up such that your ISRs do not move and your RST vector does not move, so that you can have a known password that does not change between firmware versions. I will try to work up an example to help show you how to do that, but it may take me a few days to get this to you (especially with the weekend) as it will probably involve creating a custom linker file. I will also need to know if you use IAR or CCS and what version (do you have a preference of IAR vs CCS?) For future projects on newer parts, regarding your feedback and for more context in terms of the broader MSP430 portfolio (and for anyone running into similar questions who stumbles across this thread in the future): The unfortunate thing is that you are using the old F1xx series of devices – some of your concerns are addressed on later parts (as you acknowledged). This is also why there are so many BSL versions – it’s because there have been a lot of improvements based on feedback like what you provided. I realize this doesn’t address everything, and I know that you can’t change your design at this stage, but I wanted to give you some information about your situation on the newer parts in case you do a new design in the future. #1 & #6: The F5xx/6xx and MSP432 family of parts have a Flash-based instead of ROM-based BSL that you can modify and is completely customizable – so on those you could eliminate password protection totally if you wanted, or define the password to be something besides the IVT. While there is not a way to completely disable password protection on the BSL on most of the other newer parts, your situation of losing INFO memory on a mass erase would also not be a problem if you were using the newer parts. The reason is because the mass erase on F5xx/6xx default BSL, and in the BSL on all FRAM devices does not include the INFO memory (based on feedback like what you provided). Even on some of the older parts like F2xx, there is a separate INFOA section that can be separately lockable, and with a software jump to the BSL and the correct settings you’d be able to use that to workaround and preserve the INFOA section from mass erase. With either of these methods, you would be able to simply mass erase the part and then use the default password to access it for reprogramming, and not have to worry about losing data you have stored there. The F5xx/6xx and FRAM parts also store their TI-provided calibration constants in a separate TLV area that is protected from erase or modification instead of INFO memory, so that you can't accidentally lose your DCO, ADC, or other TI-provided calibration data. BSL versions beyond 2.00.00 on F1xx/2xx/4xx parts also have some flash addresses you can use to totally disable the BSL, or disable the mass erase on incorrect password (see www.ti.com/lit/pdf/slau319 section 2.7 Password Protection for more information) #5: “Why put all this security and inconvenience on the BSL when I can just stick a JTAG programmer on it anyway?” Most users lock the JTAG by blowing the fuse on the device after they program it at production. After that is done, the device is no longer accessible via JTAG and the only access is via BSL, which is password protected. #8: Are you referring to the BSL using different pins for the UART TX/RX for BSL than the UART module in your application uses? On older parts, this was done because a Timer-based UART implementation was used for the BSL since not all parts have a UART module in hardware but you still want to be able to do updates (and I think for compatibility of the BSL across devices). However on most of the newer parts like the FRAM devices the hardware UART is used for the BSL as well so that you could match up with what you use in application. Further, the F5xx/6xx devices have a totally customizable BSL, so you could use any UART module you would like on those parts to make sure it matched up to your app. #9: Have you seen the BSLDEMO code included in the Deprecated folder with http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPBSL_Scripter/latest/index_FDS.html ? That includes source code and should support all F1xx/2xx/4xx devices (you could simply modify the .bat file, or call with the correct parameters from the command line). For the newer parts, that same download includes BSLScripter which supports everything else: F5xx/6xx, FRAM, and MSP432, and it also includes source code. For your feedback about TI becoming better at software: this is good feedback, and definitely a focus area. There have been a lot of advances since the F1xx with software and collateral, but it is an area that requires continual work and improvement. Feedback like you are providing is invaluable. I also wanted to mention Code Composer Studio (CCS) since you mentioned some concerns about tools and software support – have you tried this IDE? We also have now the TI cloud tools at http://dev.ti.com including CCS cloud, which is a cloud version of CCS with only a driver download required, free and useful for evaluation purposes, and also TI Resource Explorer with MSPWare which contains all of our collateral in one easy place – code examples, Driver Library API examples (available on the F5xx/6xx and FRAM parts), documentation, other libraries, and more. Do some of these software tools that I mentioned help with some of these larger ecosystem and software concerns that you have? I realize that not all of it (like driverlib) is helpful for F1xx, but we definitely hope that you will continue to use our microcontrollers in the future on more projects. And we value any additional feedback you’d like to give about what other specific concerns you might have on this front. Regards, Katie
↧