1K serial gdb_bootloader

[Rickta59 589]

I've been using the msp430 launchpad to program msp430fr5739 with the usual SBW. I had to get a newer mspdebug than ubuntu has because it was trying to erase the FRAM (and failing). I wonder why it wasn't working for you.

I was also using an LP v1.4

[Rickta59 589]

So I spent some optimizing the code, I got it down to 956 bytes. Feels pretty good to me for a C++ program. I doubt a 'C' version is going to knock off another 512 bytes so I'm going to stop optimizing. I'm going to focus on seeing if I can use the memory set aside for custom BSL code on the msp430fr5739. That way I won't loose any flash space to this code.

 

-rick

[spirilis 1,265]

Fantastic work!  Gaining the experience from this probably feels awesome too.

[mbeals 74]

Very timely post....I've been looking for something like this for a project I'm working on.  Do you have the source posted anywhere?

 

I'm curious...you said you hold down a button during boot and it kicks it into the BSL.  I'm assuming when the chip boots, it runs through a check to see if it should start the BSL code or jump to the main program.... Would it be possible to jump to the BSL once the main program is already loaded and running?  I'm thinking of a menu option in the CLI to enter the bootloader as opposed to a hardware interface.

[Rickta59 589]

Very timely post....I've been looking for something like this for a project I'm working on.  Do you have the source posted anywhere?

I'm actively optimizing this as we speak. I only started on this Thursday and posted what I had late Friday. It was 1950 bytes the first pass. But I was so excited about this I just had to share. Saturday, I spent the day on it and got the code size down to less than 1k.

 

The code is written in C++ using my fabooh framework. I've been trying to find a good app to use as the fabooh debut project. I think this will be it. This type of code needs to be small but needs the flexibility to use the various UART implementations. This code personifies what fabooh does well. So expect to see it real soon now, in the fabooh source tree.

 

You can get yourself in a good position to use this code if you grab fabooh from github.com and take a look at it. https://github.com/RickKimball/msp430_code

.

I'm curious...you said you hold down a button during boot and it kicks it into the BSL.  I'm assuming when the chip boots, it runs through a check to see if it should start the BSL code or jump to the main program.... Would it be possible to jump to the BSL once the main program is already loaded and running?  I'm thinking of a menu option in the CLI to enter the bootloader as opposed to a hardware interface.

Yes, I do check to see if there is code at 0xc000. If the memory contains 0xff, then I know the chip is erased and I automatically start the bootloader. If there is an instruction at 0xc000, then I actually check for the button state.

 

Originally, I had the ability to launch the newly added program using the gdb 'continue' command. However, for code size reasons, I took it out. I was also concerned that by having the ability to 'continue' people might get confused and think that it can do debugging. Which it can't.

 

To do what you want is possible.

 

-rick

[Rickta59 589]

I'm curious...you said you hold down a button during boot and it kicks it into the BSL.

Just to be clear, this code does not use Texas Instruments' BSL protocol. This code uses the GDB Remote Serial Protocol. RSP has many advantages over BSL. The biggest one is that it only needs 2 wires; TX and RX. BSL needs 4 so it can toggle the TEST/RST pins to get started. It then uses BSL TX/RX. On some chips BSL TX/RX aren't even on the real UART ports.

 

You can find more information about GDB RSP here:

 

http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html#Remote-Protocol

 

-rick

[Rickta59 589]

OK, I just updated the first post with a new 1K version. This one is half the size so it only uses 1024 bytes of flash. This leaves from 0xc000 - 0xf9ff for your user code. That is 14848 bytes for user code. Again, this is only for the msp430g2553 chip at this time.

 

You should make sure your code isn't larger than 14848 bytes. If it is, when you load it will silently ignore your requests to write over the gdb_bootloader code

 

First post link:

http://forum.43oh.com/topic/3661-1k-serial-gdb-bootloader/?p=32802

 

-rick

[Rickta59 589]

OK, I uploaded the code to github:

 

github.com/RickKimball/msp430_code/tree/master/fabooh/apps/gdb_bootloader

 

To grab this code using git, use git clone:

$ git clone https://github.com/RickKimball/msp430_code.git

or

 

you can grab a zip snapshot by clicking the "Zip" button. However you won't be able to use 'git pull' to grab updates in the future.

 

 

To compile and install gdb_bootload on your msp430g2553 chip use make:

$ cd msp430_code/fabooh/apps/gdb_bootloader
$ make clean all install

Note: this will erase the current program installed on your chip along with info segments b,c and d. It leaves infoa alone.

 

If all goes well, you will now be able to program via the serial port without the need for

a launchpad or fet. Look back in the posts here for examples of how to erase and load

new programs. There are also examples of examining memory on your chip.

 

Good luck

 

-rick

[Rickta59 589]

I updated the post above giving a how to fast track.

 

-rick

[Energy 0]

How to build client code firmware by Energia and flash via GDB?


I think it should be something like this (in boards.txt):

ocmsp430g2553.name=OnlyChip w/ msp430g2553 (16MHz)
ocmsp430g2553.upload.protocol=gdb072
ocmsp430g2553.upload.speed=9600
ocmsp430g2553.upload.maximum_size=14848
ocmsp430g2553.build.mcu=msp430g2553
ocmsp430g2553.build.f_cpu=16000000L
ocmsp430g2553.build.core=msp430
ocmsp430g2553.build.variant=onlychip
ocmsp430g2553.upload.maximum_ram_size=512

How to make Energia perform new directive [onlychip, gdb072, 9600]:
.\hardware\tools\msp430\bin\msp430-gdb.exe -b $speed -ex 'target remote $dev' '$1' (approximately, for Windows)

 

$speed = ocmsp430g2553.upload.speed

$dev = Current Serial Device

$1 = Current Energia Compiled Sketch [.........\Temp\buildNNNNNNNNNNNNNNNN.tmp\sketch_XXXXX.cpp.elf] (or need .cpp.hex?)

[energia 485]

In the current version of Energia it is not possible to set a custom upload command. We are working on a new build system that will allow you to do this but we do not have a date for this. The only way would be to create a custom upload command in the IDE. The panStamp branch of Energia already uses the gdb-bootloader. You can find it here: https://github.com/energia/Energia/blob/panstamp/app/src/processing/app/debug/MSP430Uploader.java#L65

 

Hope this helps

[Energy 0]

@@Rickta59,

It checks the button to see if you are holding it down. If not then it runs the blink.elf code. If you are holding it down, it runs the gdb server instead and allows you to reload code. So just press reset to start the blink. Press and hold the P1.3 switch down and press reset to start the gdb stub server.

Is there a real opportunity to make upload a Arduino-style?

That is, when you press the reset - start the gdb stub server; if within two seconds not starts sending data - gdb stub server is completed and passes control to the blink.

Is that possible?

 

Or by watchdog: after start unless a specific memory register is a special label - executed blink; if a specific memory register no special labels - loaded gdb stub server, to any specific memory register writes a special label, watchdog is set to 2 seconds, if you start downloading - register is cleared, watchdog reset and deactivated; finishes downloading is restarting controller.

Possible this in MSP430?

 

* Most open scheme with converters USB2TTL, and emulations USB2TTL use only DTR (one pin), and can not use other additional lines (for the second button).

[Rickta59 589]

@@Rickta59,

...

That is, when you press the reset - start the gdb stub server; if within two seconds not starts sending data - gdb stub server is completed and passes control to the blink.

...

 

Possible this in MSP430?

 

All possible in theory.  However, I'm sure it would push the code size over the 1k mark.  

 

I originally used a single pin dragged low so it would be easy to use manually with those cheap USB->TTL dongles with only TX/RX signals.  It wasn't my intent to make something that needed complicated signalling setup or any real host side support aside from msp430-gdb. If you want a hands off programming setup and you don't mind writing host code, you might look at BSL solutions which are available on larger msp430 chips. 

 

Now that TI has released the msp430f5529 LP, many of the reasons I wrote this code have been addressed.  The 5529 LP is a full featured FET that works on linux with CCS. Its firmware is upgradable and can program any chip with SBW and hopefully it will be able to deal with new chips as they are released. The 5529 LP doesn't suffer the serial port woes of the original launchpad.

 

This code fills a niche for people who don't want to program with using a full featured FET. If you have some feature you would like to see implemented, the code is on github for you to play with so have fun!

 

-rick

[greeeg 460]

This does seem to be a bit of a neihe thing. Since the FET only needs 2 wires also. and doesn't require any addition flash space used.

 

I noticed in your memory map you've allocated the whole IVT to the bootloader. can user programs use interupts? I know bigger MSP's can set a config bit to have their IVT in RAM, which would fix this issue. Or does your code program user interupts and just leave 0xFFFE to link back to the bootloader?

 

I made an MSP based MP3 player that was able to update it's fimware via a file on an MMC card. I very much like that you don't need any specialised software on the computer side to use this.

[Rickta59 589]

This does seem to be a bit of a neihe thing

 

I don't know if neihe is good or bad.  This code was really meant to replace BSL loading, which requires more complex signaling than you find in a $2 usb rx/tx dongle.  I agree, given an FET that knows about the chip you are programming, and a host program that can talk to the FET on the OS you are using, the FET is probably the path of least resistance. When I wrote this, there wasn't an FET that worked with CCS and linux.  Since then TI has released the fully featured msp430f5529 launchpad with a full featured FET that is upgradable and supported by CCS on linux.

 

Where this approach shines is when you don't want to deal with trying to get an FET working on a specific operating system.  USB serial is available on all systems without much hassle.  msp430-gdb is available on all operating systems without have to write any host code. Combine the two and you have something that is pretty easy to use.

 

 

I noticed in your memory map you've allocated the whole IVT to the bootloader. can user programs use interupts?

 

The code loads the interrupt vector table flash with the user supplied code and then replaces the reset vector with the address of the gdb bootloader start address.  The bootloader code then jumps to the normal bootloader code.  The code posted doesn't really do the right thing.  If you look at the latest incarnation used by the panstamp branch of energia you can find a version that works with the cc430f5137 and jumps to the reset vector address

 

This code was really written to highlight the fabooh c++ template library and how it can create small executables. I think I packed a lot of readable abstracted code that does something in 1k of flash ... that is really what this is about.

 

-rick