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.

MSP430F6659: Bootloader Issue - Reset problem?

Part Number: MSP430F6659
Other Parts Discussed in Thread: MSP430F6638, MSP-FET,

I recently changed from the MSP430F6638 to the MSP430F6659. The board is identical with the exception of the processor used and some additional capacitance on the 3.3V supply line. I plug the new hardware into the PC and it does not appear to invoke the bootloader on power up. I've tried using a 100 ohm resistor between VUSB and PUR to manually invoke the bootloader (per SLAA457A) and managed to invoke the bootloader on power up once but failed many times. Next, I connected the MSP-FET to the JTAG to verify that the reset vector (0xFFFE) was blank and it was. Next, I erased the flash memory (0x8000 to 0x87FFF) and the MSP430 will immediately invoke the bootloader upon completion. Further testing revealed that it does not matter what memory, or how much memory, I erased in flash as erasing 0x12345 would invoke the bootloader upon completion (with PUR going high). It was then that I stumbled upon the simplest solution, jumpering the reset to ground after power up to invoke the bootloader with 100% success.

Has there been a change in how the bootloader is being invoked on power-up?

I don't use VUSB to power the processor but use an external power circuit instead (which is powered by VBUS when no batteries are installed). Is the lag between VBUS being applied and Vcc rising to an appropriate level causing an issue?

FYI: Reset is controlled by 47.5K pull-up tied to Vcc with a 2200pF capacitor tied to ground. PUR is tied to D+ through 1.4K. Changes we've made due to previous discussions.

  • I added a MAX809 on the reset line by wiring it into the JTAG port. I now have a super clean reset that is delayed by 140ms after the specified voltage has been achieved. The board seems to enumerate every time I connect the USB.

    Is there a reason I needed to add this additional delay on the reset line to invoke the bootloader on power-up? A link to an appropriate application note would suffice and be greatly appreciated.

  • Hello,

    Check out the USB11 errata description and workaround in the MSP430F6659 erratasheet.

  • Thanks for the reply.

    Just a quick documentation note should anyone be interested: Chapter 1.3.3 referenced in SLAZ337(Y) USB11 no longer exists in the most recent release of SLAU319(AE). This chapter has been moved to 1.3.1.3. I found an old copy just to make sure that I was referencing the same information.

    1.3.1.3 Devices With USB

    Devices with USB are invoked when either of the following two conditions are met while the device is powered by VBUS:

    • The device is powered up by USB and the reset vector is blank.

    • The device powers up with the PUR pin tied to VUSB.

    Just to be clear so I can explain during our hardware review. I meet the first criteria and the bootloader is not invoked. According to USB11, to resolve this issue, I should load the CustomBSL since I can't invoke the BSL from the application code as the application code is not loaded yet.

    In my case, I forced a hardware reset with a jumper and also delayed the reset with a reset supervisor IC. In both test cases, this worked. Is there a way to verify with anyone if these are suitable alternatives before I present them at my hardware review? My superiors like options.

    Thanks again.

  • Hello,

    Just a quick documentation note should anyone be interested: Chapter 1.3.3 referenced in SLAZ337(Y) USB11 no longer exists in the most recent release of SLAU319(AE). This chapter has been moved to 1.3.1.3. I found an old copy just to make sure that I was referencing the same information.

    Thanks for the feedback. Unfortunately, when sections change in one document, it may not be clear what other documents referenced that section. I'll submit a request to update this.

    Just to be clear so I can explain during our hardware review. I meet the first criteria and the bootloader is not invoked. According to USB11, to resolve this issue, I should load the CustomBSL since I can't invoke the BSL from the application code as the application code is not loaded yet.

    That's correct.

    In my case, I forced a hardware reset with a jumper and also delayed the reset with a reset supervisor IC. In both test cases, this worked. Is there a way to verify with anyone if these are suitable alternatives before I present them at my hardware review? My superiors like options.

    I can ask for feedback on this alternative method, but the workaround of updating the device's BSL with CustomBSL described in the erratasheet will be our main and possibly only recommendation excluding invoking the BSL from the application code. My concern with using the jumper as the hardware reset is that it's very manual and may not be feasible to include/add in your final product. If the CustomBSL fixes the issue, that seems like the best approach. Like I mentioned, I'll ask for feedback, but it may be Friday until I can get back to you.

  • Hello,

    Just following up. I asked for feedback about this. There's some concern about your workaround working properly and across different operating conditions, so the guidance was to follow the published workaround for this errata to ensure it's addressed properly and robustly.

  • Thanks for the reply.