CCS/MSP430F5529: Software access to bootloader

Alex,

Would you be able to desolder an old rev MCU and replace it with a new rev on a legacy board (or do the opposite i.e. old MCU rev on new PCB)? This would tell you a lot about what the issue is and would limit the possible culprits.

OK, I've just tried bare chips in the ZIF socket of my MSP-FET430U64 dev board. 

Rev.C and Rev.E chips work correctly.

The Rev.K  parts on my new build DO NOT work correctly.

The virgin chip comes up as a HID device which I can load firmware into. However a software BSL call (PC to 0x1000) fails, the part simply restarts as a CDC device. Physically pulling PUR to Vcc during power up does access the bootloader.

I have a batch of dud units. Suggestions? How to get TI assistance on this?

Alex,

Since the newer devices entered USB BSL correctly via the HW invocation, and they seem to be working fine otherwise, this leads me to believe this is a SW issue and not a HW issue. Looking from the revisions you are dealing with, a lot of USB and BSL fixes have been implemented. It could be an incompatibility with the version of the USB BSL on the newest chips versus your normal SW.

A few things I would try:

• Before entering BSL via SW entry, make sure to reset peripherals the USB BSL uses to a reset state (Timer B, USB,etc.).
  • These peripherals need to be reset to default states before SW entry. this is due to the fact that the BSL was built on the assumption that you just went through a Reset and the  peripherals it uses are in default states. This is not the case when doing SW entry as the registers are kept in the last set state instead of default. The BSL User Guide was updated recently to include all the peripherals it uses, so these adjustments can be made.
• Make a simple bare program that just enters USB from SW entry after a certain timeout or button push.
  
  • This would be used as a test to make sure the simplest SW is working correctly.
• Update BSL tot he newest version
  
  • We periodically make updates to the BSL that may have not made it to the newest revision of the chip yet. Updating the BSL could fix some issues that have already been worked around.

Jace, I've gone back to square 1, demo app "C1_LedOnOff" (where my app began) on the MSP-FET430U64 tool. I've added the USB BSL access code from slau3190.pdf page 28.

On a Rev.K part, this code works and I can trigger the bootloader succesfully.

This points the finger at Timer B, because the demo app only uses Timer A, whereas my code uses Timer B as the main Tick timer.

Therefore advice please - what exactly do I need to do to reset Timer B to a condition in which it will not upset the Bootloader? Simply stopping the timer didn't work.

As stated in my last post, I've done all of this, timer registers restored to datasheet default values, and suggested code fragment from the BSL app note to disable interrupts and disconnect USB. It still exhibits the fault. What has changed in the bootloader so my code no longer works? What other resources does the BSL need?

Alex,

I outlined what the BSL needs in my last reply. Namely it needs TimerB and the USB stack disconnected if it was already used before being called. Also, disabling the GIE is advised as interrupts could interrupt the BSL process. Other than that, the only thing I can think could be an issue is the VCORE settings. The USB BSL changes the clock speed to 8MHz and should change the VCORE level to level one. Of course, it may assume the VCORE is at standard reset level of 0. There shouldn't be an issue if you are at a higher level of VCORE and clock, but it is something to test out. RAM is cleared when going to BSL so that shouldn't be an issue.

One debug effort that can be done is to comment out sections of your code and try to go to SW BSL to see what settings are affecting your entry. As you stated, TimerB is suspect so if there is any way you can not use/setup TimerB in your project  (temporarily) and see if the problem persists. this could give us some clue as to what is causing the issue.

The "TI Thinks Resolved" was pressed earlier in our conversation as I had thought I had gotten a solution to you. If you look at that particular reply, you can reject this notion. Obviously the issue is not resolved yet and I am still working with you to try to resolve it.

I am using the full code fragment from the BSL document;

__disable_interrupt();
USBKEYPID = 0x9628; // Unlock USB configuration registers
USBCNF &= ~PUR_EN; // Set PUR pin to hi-Z, logically disconnect from host
USBPWRCTL &= ~VBOFFIE; // Disable VUSBoff interrupt
USBKEYPID = 0x9600; // Lock USB configuration register
__delay_cycles(500000);
((void (*)())0x1000)(); // Call BSL

and additionally resetting Timer B to reset condition, no joy. I was going to switch to Timer D, but of course this isn't present in my part. That only leaves Timer A. I'm using an 8MHz clock and Vcore level 3. I'm still hacking around in the hope of a breakthrough.

Jace, designer support is a key factor in my choice of supplier, I had thought to evolve the design towards the MSP430F5659 to give more memory, in the absence of an MSP432 USB part. However, given that you no longer have field engineers, and I'm left to figure out my own problems caused by a TI chip revision, I'm not so sure. I'll carry on with the diagnosis but a bit more proactive help from TI would have been nice.

The "TI Thinks Resolved" was pressed earlier in our conversation as I had thought I had gotten a solution to you. If you look at that particular reply, you can reject this notion. Obviously the issue is not resolved yet and I am still working with you to try to resolve it.  I can't find the 'reject' option anywhere in these posts. 

I'm going to need some pointers on that, it is delving deeper into the Msp430 entrails than I really wanted to.