How to get from here to there (ccs v3.1 --> ccs v5.x)

Chris,
I am guessing that your 6433/bios 6.30 branch uses CFG scripts for configuration. That's the default option, and since the projects are newly developed, it makes sense that they are developed using CFG scripts. There are ways to use TCF scripts, but that's usually being done for projects updated from bios 5.xx to bios 6.
So, if you are using CFG scripts for the new branch, you'll have to create CFG scripts for the old branch too. You could try cdb2tcf conversion, get the project working in ccv3, and then convert the generated TCF script into a CFG script. However, the resulting CFG script could end up complicated and difficult to maintain, not to mention that you may end up spending a lot of time solving ccsv3 and Tconf related problems that won't matter for your final goal, which is to get everything working in ccsv5.

I would recommend you to run cdb2tcf conversion and then use the generated TCF script as a reference for creating a brand new SYS/BIOS 6 project in ccsv5. There is a document Bios_Legacy_App_Note.pdf in SYS/BIOS 6 installation that should help you, together with the Bios_User_Guide, with translating your TCF configuration to a new CFG script.

As for the compiler tools, I wouldn't bother with the old version. The new version should compile everything that the old version compiler.

So, to summarize, I think you should start with the converted TCF script and your bios 4.9 C sources, and use the documents mentioned above to create an equivalent project for ccvs5 and SYS/BIOS 6. It's definitely not going to be easy, but based on the description of what you need to do, there is no really an easy path to do that.

Feel free to open new threads as you encounter specific problems along the way.

I know from an engineering pov getting everything current is the way to go, but commercially this sounds like a long time...

Is the 6433 chip supported in earlier versions of the tools?

So if I overcome the problems getting from bios 4.9 to 5.x and code gen tools 6.x* could I then bring the new code back to that level?

Then I could do some useful development, have comminality and then address the getting current issue later.

Chris

* I can get to 6.0.8 now (with bios 4.9), but 6.1.20 breaks the alignment???

TMS320DM6433 is supported in DSP/BIOS 5.41. You can rewrite your code that uses SYS/BIOS 6 APIs to work with DSP/BIOS as long as you don't use any functionality added to SYS/BIOS 6. I don't think there is any document that specifically describes which APIs are added, but I'll ask someone from the SYS/BIOS team what could be a problem when moving from SYS/BIOS 6 to DSP/BIOS 5.

Perhaps I will jump to that version.

I have spent the day trying to get BIOS 5.20 to work, the idea being to transport myself back several yrs and apply the new stuff as it would have happened, hence the smallest possible steps.

The project uses things like emif, dma and irqs, but from the cdb none of this is configured, so when it does a tcf conversion it thinks there is no CSL stuff to copy. I put in a dummy timer to make it drag in CSL stuff, fixed it all up to build and still it dies on me.

Right now I am trying to work out which bits of CSL to force it to include.

Chris,

I sympathize with your situation.

I think Sasha's advice is sound. I do encourage you to ultimately get to a pure SYS/BIOS 6.33 based application when it is feasible.

I assume you've seen this document that describes migrating from BIOS 5 to BIOS 6. But just in case, here's a link to it.

    http://www.ti.com/lit/an/spraas7e/spraas7e.pdf

While the build flow is a bit different between BIOS 5 and BIOS 6, there's only a few modules and module APIs that SYS/BIOS provides that can't be somehow duplicated in BIOS 5. Section 1.2 of the BIOS User's Guide summarizes the new functionality of SYS/BIOS:

    http://www.ti.com/lit/ug/spruex3j/spruex3j.pdf

As long as the BIOS 6 code you're starting with doesn't use any of the new features described in section 1.2, I think you'll probably be OK.

Alan

I guess right now I am in stubborn mode and will beat it into upgrading...

But it is worrying what is so difficult about this code base, why will it not upgrade. About 5-6 years ago hundreds of developers got bios 5.2, followed the instructions and left 4.9 behind without another thought - why will it not work for me?

The code base started life about 10 years ago, was there some other style of doing things back then, that could only be upgraded as far as 4.9. It does seem strange to have the code half configured in a gui (threads) and half configured by code (semaphores etc), so perhaps it is the result of a half upgrade from some earlier era.

Hopefully someone else has been this way before and can tell me what they did?

I tried a different tack, lets get all the code up to 7.3.2. More landmines...

(I skipped the latest of the 6.x since I need quad alignment of sections, I cannot see how to make this happen in 6.x, while I could hack the cdb in v5.x)

One of the simpler programs failed to load properly - this is a non-trivial affair where another program decodes the coff file and sends it over optic fibres into the ram of the target - but for all this complexity it basically copies or fills ram according to the coff file.

After a couple of days of joy I have determined that for the same input files (ccs v3.3 and bios 4.9) the linker marks the heap to be filled and .trace and $BRID to be loaded.

Some hand hacking of the coff file to clear the attributes so making these sections ignored and my box came up.

Now how on earth do I tell the linker not to do this?

I can end the year with a very slight victory :)

Chris,
when you are saying that you skipped 6.x, do you mean you did not want to use the 6.x compiler, or you are referring to SYS/BIOS 6.x? If you are using the 7.3.2 compiler with the linker command files generated by BIOS 4.9, which I advised you to do, you might have a problem that I forgot about. In BIOS 4.9, we generated linker command files relying on some linker functionality that changed since then. I don't remember details, but I could try to dig out something if we cannot get your apps working any other way.

So, back to the problem at hand. So, the original app does not have the heap filled, and .trace and $BRID are not loaded, and that version of the app loads correctly. But when you use the same generated C files and the linker command files, and build them with 7.2.3, the heap is filled, .trace and $BRID are loaded, and the app does not load. Is that what's happening? Can you post your generated linker command file? There could be an option where you just pass another linker command file to the command line before the generated command file, and in your linker command file you could allocate sections the way it works for you.

BTW, what's $BRID?

Hi Sasha,

Yes, I had previously been trying small ordered steps, having got nowhere that way I leapt right to the newest compiler, I had tried 6.x before but got clobbed by the need for quad align sections, a peculiarity of our system.

Yes you have the right idea, the filling of sections kills the loader application running on the dsp in the target hardware [from flash] which recieves the main program over the network.

The $BRID section is nothing to do with me, some sort of dwarf debug info? - http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/3274.aspx.

Which linker command file do you mean?

When I am next in the office I was going to look into the --hide option for the linker to just make these sections go away.

Ta

Chris

Chris Thomas said:

Which linker command file do you mean?

A DSP/BIOS configuration generates a linker command file, with the extension .cmd. That's where section allocations are defined.

Sorry for the delay, vpn troubles.

I have attached the file, I can see how I can mod this to stop the trace section getting filled, but there is no mention of the BRID section.

Chris

Soted it in the end by writing a program to modify the COFF file in the post build step.