Jump to content
chicken

Why is UART BSL not RXD/TXD?

Recommended Posts

Why on earth would TI engineers use random GPIO pins for the built-in UART BSL instead of RXD/TXD of one of the USCI peripherals??

 

post-9974-0-31045800-1463460203_thumb.png

 

I mean, in 90% of real world use cases, the likely source of a firmware update, i.e. computer, USB bridge, blue-tooth modem etc., will be hanging on one of the UARTs.

 

Instead they picked 2 pins on the side of the package where all the I/Os are nicely lined up and which therefore most likely would be wired up to all the other stuff. Oh yes, and of course those two pins are exactly on the opposite side of the TEST / BSL enable pin. :angry:

 

/rant

Share this post


Link to post
Share on other sites

It is assumed that a firmware update is done through a separate connector on the board, not with same existing serial interface.

 

In any case, you can exchange the BSL with the USCI-based BSL, or just change the pin assignments.

Share this post


Link to post
Share on other sites

I believe that the BSL ROM pre-dates the USCI module. It seems to use the TA capture compare pins.

 

So changing to the USCI would take extra effort, and possible break backwards compatibility.

 

But I do understand your frustration.

Share this post


Link to post
Share on other sites

Argh! Just locked myself out of the SBW while trying to flash my own BSL :-X

 

MSP-FET says the fuse is blown, but I think I borked the BSL_Protect call by not setting the JTAG lock bit. Happens that the BSL example project does not set that bit.

 

Again "why on earth!" Why would anyone publish example code that will lock CCS out of debugging things??

 

Time for a beer or two.

Share this post


Link to post
Share on other sites

Argh! Just locked myself out of the SBW while trying to flash my own BSL :-X

 

MSP-FET says the fuse is blown, but I think I borked the BSL_Protect call by not setting the JTAG lock bit. Happens that the BSL example project does not set that bit.

 

Again "why on earth!" Why would anyone publish example code that will lock CCS out of debugging things??

 

Time for a beer or two.

 

That sucks :(

Share this post


Link to post
Share on other sites

If I'm lucky, the flashed BSL works. But I will have to solder a few patch wires to wiggle TST and RST/NMI before I know.

 

For another "why on earth" reason, the F5232 has two reset pins, with one required to connect for SBW and the other used by the BSL. Of course I had that backwards in my layout as well.

Share this post


Link to post
Share on other sites

Actually, looking at the table at the top of this thread, SBW reset should also work for BSL. So hopefully I can use the SBW pins without additional patch wires to initiate BSL.

 

Will know tomorrow, after sleeping off the beers. :-)

Share this post


Link to post
Share on other sites

Nope, beer didn't help. Even started a small Energia project for a "BSL Explorer", using the recently discussed simple command line parser.

 

I gave up and replaced the MCU with a new one. I might give it a new try with a RAM-based BSL at a later point.

Share this post


Link to post
Share on other sites
chicken, on 17 May 2016 - 12:52 AM, said:

Why on earth would TI engineers use random GPIO pins for the built-in UART BSL instead of RXD/TXD of one of the USCI peripherals??

 

attachicon.gifMSP430_UART_BSL_grrrrr.PNG

 

I mean, in 90% of real world use cases, the likely source of a firmware update, i.e. computer, USB bridge, blue-tooth modem etc., will be hanging on one of the UARTs.

 

Instead they picked 2 pins on the side of the package where all the I/Os are nicely lined up and which therefore most likely would be wired up to all the other stuff. Oh yes, and of course those two pins are exactly on the opposite side of the TEST / BSL enable pin. :angry:

 

/rant

 

Is this just a simple case of TI using the same BSL for all devices to avoid exceptions and differences? Using GPIO for the BSL makes sense if you consider that the lower value line devices like MSP430G2x/i2x have no UART in hardware.

Share this post


Link to post
Share on other sites

Argh! Just locked myself out of the SBW while trying to flash my own BSL :-X

 

MSP-FET says the fuse is blown, but I think I borked the BSL_Protect call by not setting the JTAG lock bit. Happens that the BSL example project does not set that bit.

 

Again "why on earth!" Why would anyone publish example code that will lock CCS out of debugging things??

 

Time for a beer or two.

 

When I was working on my BSL, all testing (with logs) is done by using main flash, without touching BSL flash area. (In any case) BSL was copied to RAM and executed from there. At the and it was relocated to BSL area, and flashed, after I was 100 % sure that everything is OK with generated (2 KByte) TI txt file.

Share this post


Link to post
Share on other sites

When I was working on my BSL, all testing (with logs) is done by using main flash, without touching BSL flash area. (In any case) BSL was copied to RAM and executed from there. At the and it was relocated to BSL area, and flashed, after I was 100 % sure that everything is OK with generated (2 KByte) TI txt file.

 

That sounds like a sensible approach. While testing, did you you rewrite the entry vectors in the BSL segment, e.g. BSL_Protect, or did you enter BSL from main?

Share this post


Link to post
Share on other sites

Alcohol helps creativity.

Scientifically proven.

Maybe you didn't give it enough of a chance to help?

 

I'm just kidding... or am I? ;)

 

Only when consumed socially. Back in the day (.com bubble) my theory was, that ideas from the Friday night pub crawl which you still remembered on Monday morning must have merit.

Share this post


Link to post
Share on other sites

That sounds like a sensible approach. While testing, did you you rewrite the entry vectors in the BSL segment, e.g. BSL_Protect, or did you enter BSL from main?

 

During development / testing original (TI USB) BSL was untouched. My BSL was placed in main flash, started by RESET vector and copied to RAM. Main flash was not used anymore and it was ready for user program. After downloading user program by RAM BSL, and device reset, user program was started.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×