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.

MSP430F2131: MSP-GANG "ERROR 68: FBSL initialization error" when attempting to program the MSP430F21x1

Part Number: MSP430F2131
Other Parts Discussed in Thread: MSP-GANG,

The MSP-GANG Cannot program MSP430F21x1 chips using the BSL. The communications between the PC and the MSP-GANG fail shortly after the FBSL or Fast-BSL has been loaded. I gave a very detailed account of this bug in an earlier post over 10 years ago! Still nothing has been done to fix it. I was recently bitten by this bug again and thought I would re-post.

This is NOT a corner case, TI's official programmer cannot program a single F21x1 chip that leaves the factory using the BSL.

My previous observations still stand and nothing has changed, so I won't reiterate all that, just refer the reader to my previous post.

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/290004/msp-gang-error-68-fbsl-initialization-error

In an effort to illustrate this problem, and pre-empt the usual "you are doing it wrong" response, I have laid out a board with just the essential components. See the attached photo.

On the board is the MSP430, a 100nF Vcc bypass capacitor. a 47K pullup resistor and a 2.2nF capacitor to ground on the /RST pin, as specified in slau278ah, Figure 2-1.

I have assembled three such boards and loaded then variously with

MSP430F2121T Rev E

MSP430F2131T Rev I

MSP430F2131 Rev K

All three boards present the same problem. These are all the chip revisions I had on hand. I have no reason to doubt all earlier and later silicon revisions would behave the same.

The JTAG works fine and can read out the memory of the (Blank) chips.

The BSL fails with error 68 shortly after loading the FBSL.

I don't know what else I can do to convince TI / Elprotonoic that this is a real problem and not just user error.

PLEASE FIX THIS BUG!!!!!

PLEASE FIX THIS BUG!!!!!

PLEASE FIX THIS BUG!!!!!

  Regards,

     Sean Gallagher.

log..

Openning target..Done
.............
  4 : init target
  5 : Loading FBSL
  6 :
ERROR 68: FBSL initialization error
ERROR 68: FBSL initialization error
ERROR 68: FBSL initialization error
Closing target..  0 : Finished
ERROR 68: FBSL initialization error

  • I have now built up and tested boards with

    MSP430F2131 Rev D

    MSP430F2131 Rev G

    So far tested Rev [ D, E, G, I, K ] and all show the same problem. JTAG works fine. BSL works fine. FBSL fails shortly after loading with Error 68.

  • Hey Sean,

    Thanks for bumping this thread.  As you've noted, I expect the debug to behave the same across all revisions unless documented in the Errata document.  But I don't see any BSL related changes since Rev C.  

    Can we also confirm that you are using the latest software version for the MSP-GANG?  It looks like v 1.03.08.00 is the latest, released in August of last year.  

    Also, I've reached out to my contact at ElProtronic to take a look at this from their side.

    Thanks,

    JD  

  • Sorry, I accidently hit the "TI Think's resolved" button.  Updated that.  Will leave this thread open for now.  

    Thanks,

    JD

  • I doubt this problem is related to the Mask-Programmed BSL. That code is only used to download the "Fast BSL" into target SRAM. That step is working properly as best I can tell. The problem occurs when the MSP-GANG attempts to set the target DCO for FBSL high speed operation. It seems the target DCO clock is set (far) outside the operational limits of the FBSL protocol. The MSP-GANG does not seem to "tweak" the value written for a particular chip, but rather uses a One-Size-Fits-All approach. The FBSL protocol seems quite tolerant to DCO frequency spread - but it still has it's limits.

    So either the (RSEL,DCOx) register bits to DCOCLK frequency mapping has changed over silicon revisions, or a bug has appeared in the MSP-GANG software. Either way, the function is effectively useless now and needs to be fixed.

    I'm not sure if a change in the nominal DCO frequencies would be mentioned in the errata as the original specification is quite loose to begin with. Even relatively large changes in nominal frequency could still be within spec.

    Yes, I was careful to use the latest MSP-GANG software in my testing, although the problem has been around for many years.

**Attention** This is a public forum