MSP430F449: synchronization error BSL

Hi Sergei,

if I understood correctly you have some issues with the MSP430-BSL-USB programmer by Electronicfans. I'd suggest for you to get in contact with the supplier directly as I don't have details on their device.

Nonetheless I'd suggest for you to also check out the MSP BSL solutions provided by Texas Instruments and we can defintely help you to get started with those.

Please let me know in case there are any questions on the MSP BSL.

Thanks and best regards,

Britta

OK! Thank you.

But that this http://www.ti.com/tool/mspbsl I did not understand! There is an archive with some files. What should I do with them?

Sergei Huiva said:

I've got one more question: if I buy such a programmer olimex.com/.../ I can fully read and write code with MSP430F449? And if the fuse is turned off, I can write code into it?

I'm not sure the Rocket will work well with the F449.  My understanding is that the Rocket is intended for parts that are programmed with BSL-Scripter (the F5xx and F6xx parts), but your F449 is programmed with BSLDEMO.  This wiki entry suggests BSLDEMO does not directly support the Rocket:

http://processors.wiki.ti.com/images/tmp/f1391570252-215069158.html

While options are presented there to make it work by jumping through hoops, it seems to me that the Rocket may not be the ideal solution.  TI people reading this will see that table 1 of SLAU319 does show the Rocket as being appropriate hardware for programming these parts with BSLDEMO.  I would question that unless a big footnote is added.  But perhaps I misunderstand what the Rocket does.

Sergei, does the documentation for the programmer you have say it is only for use with BSL-Scripter, or only for F5xx and F6xx parts?  If not, you might try running BSLDEMO with it to see if that works.

Britta Ruelander said:

Hi George,

you've made a good catch here. We're updating our documentation (SLAU319), as the Rocket is not supported on F4xx devices. We need to remove it, thank you for highlighting it!
Also, we'll remove the wiki page you've hightlighted above, as this is no the supported way, again many thanks for making us aware that this is still up.

Best regards,
Britta

Britta, I understand that you want good information out there, but I would have suggested the opposite approach - adding a footnote in 319, and leaving the wiki entry as is.  Remember that the Rocket *can* be used with these parts if you jump into BSL from the application, which continues to be an approved practice.  The real problem is that TI doesn't have a low-cost device to program these parts, and when people try to use an FTDI or other typical USB-to-serial adapter, they find that BSLDEMO doesn't work with them because of polarity issues on DTR and RTS.  So you end up referring people like Sergei to my version of BSLDEMO on Github, which solves the polarity problems, but isn't exactly signed TI-source software..  I take it back.  You do have the low-cost option presented in SLAA535 - a G2 Launchdpad and the G2452 that comes with it, but the user has to program his own interface device.  So again, I would hope that some version of the wiki entry could be left in place, and a footnote added to the Rocket checkmark in 319, at least until such time as the official version of BSLDEMO allows individual polarity control of DTR and RTS.

Britta Ruelander said:

Hi George,

thanks for the feedback. Let me take this back to our experts for the programming tools so that they decide on the best way to support customers on those issues. We'll definitely take this remarks into account and might need to update our documentation and maybe code examples accordingly.

Thanks and best regards,
Britta

Just to make you familiar with the history of the DTR/RTS polarity problem when using third party USB-to-serial adapters (FT232, CP2102, CH340, etc.), I requested an option be added to BSLDEMO to allow polarity control of DTR so those adapters would work.  In the version of BSLDEMO included in Scripter v3.3.0, an -i option was added, but it inverted BOTH lines, which just transferred the problem to the other line.  Just a misunderstanding about what was needed, probably my fault. Then in the current Scripter 3.4.0 ZIP, that option was removed, so we're back to the v3.2.1 state, with no polarity options.

DTR needs to be inverted in all cases to work with the third party adapters.  RTS is currently correct for MSP430 parts with Test pins, but needs to be inverted for those with TCK pins.  However, to keep from breaking all the existing devices that currently do work with BSLDEMO, those inversions need to be added as non-default options.  In my recompile of the v3.2.1 version, I added -i to invert DTR and -j to invert RTS.  So all possible polarity combinations of those lines are possible.

My modified source is included in my Github repo, and of course TI is welcome to use anything there that might be useful.  All of my source code changes are preceded by "/*  Change by GH */".  I assume TI doesn't typically feel compelled to support use of third party devices like these adapters, but the closest thing TI has to a low-cost BSL programming device for all the BSLDEMO devices is the one shown in SLAA535.  The Rocket can be used, but it doesn't support the signalling pattern on /Reset and Test when used with BSLDEMO.  Of course MSP-FET can be used, but it's ten times the cost., whereas the third-party adapters are a couple bucks.  In fact, the whole point of my Github repo was embedding these adapters in MSP430 circuits, so only a USB cable would be needed to flash new firmware.

If TI does decide to implement the polarity control, I have a couple other changes to offer in the "while you're at it" category, but won't bother you with those now.

You would also need to think about what changes to make to Table 1 of SLAU319 - -perhaps an additional line under Hardware for "third-parry adapters", with a checkmark for that one column only.

Good morning, Britta and George!

Thank you very much for your help. You provided a lot of information. Concerning MSP-FET, the problem is not even in value but in the fact that I can not buy it in Ukraine. All I could buy is the programmer that I wrote earlier. I would like the products TI to have Russian-language support. 

Thanks again to all!

Thank you, George!

The module that I have is built on a chip CH340T. Installed drivers, checked for 3.3 v.I already downloaded your version of BSLDEMO, thank you very much! But I did not fully understand how it works. Where can I find this information? Can I read data from the microcontroller without knowing the password? Can I count on your help with my project? If I have any questions, how can I contact you?

OK! But after erasing, can I write down my code again in it? What it is 

How to use it? No information...

Hi Sergei,

I've taken your case back to the responsible organization inside and indicated that a documentation update may be needed.

Thanks a lot for your input and you're right, this can definitely be important for other user's also.

Should I go ahead and close this thread?

Best regards,

Britta

Hi Britta!

Yes, I think the topic is revealed. But I'm interested in another question: as far as I understand the parameters -i and -j inverted signals DTR and RST, knowing the correct direction of these signals, can I invert them using hardware? Let's set the logical element NOT.

Sergei Huiva said:

Hi Britta!

Yes, I think the topic is revealed. But I'm interested in another question: as far as I understand the parameters -i and -j inverted signals DTR and RST, knowing the correct direction of these signals, can I invert them using hardware? Let's set the logical element NOT.

Sergei, my purpose in adding the -i amd -j options was to avoid the need for hardware inverters, but still allow polarity to be changed.  But you certainly can use hardware inverters instead, and that would allow you to go back to the official TI version of BSLDEMO.  The -i and -j options apply to the DTR and RTS (not RST) outputs of your USB-to-serial adapter.  Those are the lines BSLDEMO uses to initiate a BSL session, as described in SLAU319.