Merging bootloader bin to main project bin

I'm using CCS6.

Not directly related to CCS, but a tool like SRecord (http://srecord.sourceforge.net/) could do the job as well. Despite it's name, it deals with many formats, including BIN. And yes, it can merge several files together. It had been widely in use in my last company.

I'm no CCS user, but since it is Eclipse-based, you could probably call it in a post-build step in the project settings, like in most Eclipse IDEs.

Thanks for the tip. That will probably do the job. I need to test it. But still I'm curious what kind of post build step I need to create to get this thing done automatically. If someone can point me to right direction, I would be pleased.

On a "plain" Eclipse IDE, it looks like this:

I'm not much of an Eclipse fan, though ...

Since I can't see the posted image myself, here the next try ...

Yeah I know where to put the magic command, which will do the job, but the problem is that I don't have any idea what kind of script it is. And also I don't know where start to look for the correct script.

Not necessarily a scipt, a plain command call does as well. You would probably want to give the input/output file name as Eclipse-defined environment variable, instead of fixed names. Something like "$(PROJECTNAME)", or however Eclipse calls it.

Perhaps some CCS guru can help you here with specific hints. My company has multi-vendor requirements, so we use an appropriate toolchain (IAR-WB).

Hello Tomi

Why do you need to merge in the files. The bootloader can be flashed and then it can be used to download the main application binary.

I can imagine a use case where the bootloader and the application are separate software projects, but the produced devices should leave the company (production) pre-flashed with an application.
The bootloader is mainly for field updates - at least that's the way my company does it ...

Likewise, JTAG is often faster than the interface used for field updates and the programming can be done before the necessary connections for field programming are available. Not to mention the need for two, possible quite different, programming steps in production. Although using ccs for production load seems unoptimized.

Another approach is to use a proper programming utility. Many of those will do the merge dynamically or perform the two downloads in sequence from a single call. That relieves the burden of maintaining a third binary.

Robert

Although using ccs for production load seems unoptimized.

As I understood it, the OP is just looking for a way (automatically) create a combined binary when rebuilding his projects, which can then be handed "down" to the assembly line folks. I don't see CCS in "production use" in that scenario.

Hmm, I think you're right. I misread it.

Definitely worth looking at the programming utility in that case. Even if it has to be called twice that's a simple script and it saves maintaining 3 binaries, keeping the development of the two as independent as possible.

Robert

Mastermind is correct. It would be nice that I get both bin merged together automatically. And then I can just send the .bin file to production. If the worker in production needs to write two separate .bin files to board and change some settings between the updates, there might be problems. So if I can minimize the risk doing flashing wrong, I will try it.

But back to the main problem. It starts to look like there is no easy answer here. Can I somehow merge bootloader project and my main project together? And then when I hit compile the CCS builds both projects and linker somehow puts those together?

The aggravating constraint is that both parts, bootloader and application, have to go to fixed addresses. I'm not a CCS user, and can't give definitive hints.

But I guess the bootloader would be rather stable (i.e. rare changes, few versions). Thus, I would add the bootloader object in the post-build step of the application.

We have a similar use case here, but use IAR-WB and another Cortex M4 MCU. With that IDE, you would have to modify the linker file (*.ICF) to achieve placement at fixed locations. However, the MCU board is part of a much larger system (actually less than 0.1% in weight and costs), so assembly line programming is not really a concern. In fact, bootloader and application are only combined for testing purposes - and with a self-written tool. For the real production, flashing the application is one of the last steps.

Tomi Leinonen said:

And then I can just send the .bin file to production. If the worker in production needs to write two separate .bin files to board and change some settings between the updates, there might be problems.

That's why you don't provide them with options. Just use a script.

Depending on how you set it up they either run the script from the command line or a mouse click. 

You maintain the advantage of keeping the development of the bootloader and application separate and still have the advantage of a single programming step. Not only that but since it is all scripted you also do not need to worry about the user accidentally selecting a wrong option in the programming interface.

All the programmers I've used are fairly easily scriptable from the command line. If the one you are using is not it speaks to the quality of the device.

Robert

I just finished a functional test jig that does this as part of the test. It programs the bootloader and a test application, runs the test and then programs the final application. The operator simply runs the test application, no need for further involvement other than putting the board in the test jig and removing it when done.

Hello Tomi,

I understand the use case of yours. Let me see if I can make a small application that can merge two bin files into a single one. It could be well a part of the TivaWare as well.

Hello Amit. Did you managed to create example project?

Hello Tomi

Not yet, I have been busy with some other activities. However a google search shows there are some interesting utilities on the web.

superuser.com/.../concatenate-binary-files-in-windows-without-command-line

You can try a few of the utilities while I try to get back to developing another one.