MSP430FR5994: BSL Mass Erase On MSP430FR5994

Hi Mike

What's the host do you use?

The MPU is enabled by the CCS default, have you disable  it?

Have you try it in a blank device? 

Hello Gary,

Thanks for the reply...  Regarding your questions...

1.  For host, I assume you mean HW it is attached to...  The HW is a custom board...  Thats why I was curious if we were missing some key HW connection to allow mass erase...
2. We do use the MPU - and have it setup.  We do not use the IPE section of that module.  From what I have read, only the IPE section would block the MASS ERASE... 
3. I have not tried a blank device.  I'll have to investigate if I can...  This chip will not automatically go to the BSL on blank detection...  And we do not have a programming board that tickles the RST and TEST lines as of yet...  Right now, we have been using our software application.  We send a command via UART to our application, and then the APP will jump to the BSL using the info from the BSL guide.

The odd behavior is that we can do firmware update without mass erase by setting the password and sending the firmware image. 

I can easily try disabling the MPU before we jump to the BSL.  And will also try disabling completely and jumping to the BSL...  As for the blank device, as of now I cannot do that.  our programming header does not connect the emulator (MSP-FET) to the UART pins...  And this MCU will not jump to BSL on blank detection...

Thanks,

-mike

Gary is your expert here, but I have found that entering BSL from a running application can be problematical because things may have been changed since bootup in ways the BSL doesn't expect, and which wouldn't have happened if entered immediately after a reset.  However, it is surprising that everything seems to work except the mass erase.

I think it might be useful to try using the Test/Reset invocation trigger to see if mass erase works with that.  There's a version of Scripter for Windows that has the option to generate that pattern and allows you to use a generic USB adapter as the hardware interface (so long as it includes DTR and RTS).  See the Releases in this repo:

https://github.com/drcrane/bslscripter-vs2017

But I have to raise the same question I raised in another thread.  Why do you need to mass erase?  This is an FR part, and you say you are able to update firmware successfully without the mass erase.  Why do you need to erase anything?

Hello George,

Regarding entering BSL via the application, I agree...  Everything works except the mass erase...  The mass erase only causes a reboot...  I can only assume that we have the correct settings when entering the BSL from the application since every thing practically works...

The code to jump to boot is very simple and similar to the example in the guide...

• We turn off the UART, and clear the registers (allow BSL to use)
• disable interrupts
• switch our clock to use the DCO at 1MHz
• software delay of thee cycles
• Reset the FRAM to the new DCO clock timing
• Another SW delay - 10 cycles
• Jump to boot - ((void (*)())0x1000)();

Not sure what else we would need to get mass erase to work if all else is working...  When we read data out, and then jump to the reset vector back into our application, that also works fine...

To answer your question about why the need for Mass Erase, our goal is to avoid having to deal with password maintenance for doing a firmware update for the many debug builds we hand out to the HW team...  During our development cycle, we have many iterations of builds (and some generic HW test builds).  We don;t want to have to maintain a list of all the passwords, and then correlate them to all the different debug builds...  And as of now, we only have a handful of MSP-FETs (we could use uniflash).  Our goal in the end is to have a single tool using BSL to read/write data we need if programming, or to mass erase if we don't remember the build that is on the MCU...

Regarding the Test/Reset invocation...  We have plans to add that functionality to our programming board and to our PC tool that communicates via BSL.  However, that will not be available till probably late this week to early next week for the HW.  SW depends on the next priority (firmware updates vs application commands, ect)

Thanks,

-mike

I understand.  Well it will be interesting to see what the solution is.  In the worst case, you could use a jump table for the vectors so every version would have the same password.  But mass erase should just work.