CCS Team, (your input was already evident on some of this info)
Our customer is attempting to move from v3.3 to v11 and is experiencing a variety of build issues.
We have suggested an iterative approach - moving from v3.3 to v4, and so on.
But regardless of the 'how' this is the latest thread that needs some level of attention please.
-----
[CUSTOMER] We have a legacy code which was developed using CCS V3.3. Now we are migrating that code to CCS V11.1, during this migration we are facing some issues.
Can you please help?
---
[TI] Indeed, we are here to help.
But I have to say that this is a pretty big jump from V3 to V11. This is years of revisions.
That said, we do have some nice Migration Guides online to support this type of exercise.
This one, in particular, can move you from v3 up to v9 and you can then follow the same general steps up to v11:
https://www.ti.com/lit/an/spracr4a/spracr4a.pdf
-----
[CUSTOMER]
The TI DSP PN is TMS320F2803X.
We have done some activity for Code migration from CCS V3.3 to CCS V9, We followed the steps as mentioned in below TI Doc. Shared
https://software-dl.ti.com/ccs/esd/documents/ccs_legacy-project-import.html
Also we captured the steps in attached doc. I.e.”import_to_9.docx”.
We got some warnings related with linker file in migrated code. Also got some errors for stack, But we resolved those errors. We captured warnings in attached document I.e “Warnings.docx”.
We need your help to resolve those warnings. Your help will be appreciated.
-----
[TI] I first have to say that this is a challenging endeavor. Going from CCS v3.x to V11.x is nearly 15 years of updates. In a perfect world, one would attempt to move from each Major rev forward (ie 3.x to 4.x and so on). But I understand your desire and need to make the full jump here.
However, the references to the Flash-API and such means to me that you are digging much more deeper than just the CCS compile process.
Anyway, in speaking with our Compiler Team here at TI earlier tonight, here goes with some input:
Regarding the no matching Section diagnostic … This is saying the line …
-l2803x_FlashAPI_BootROMSymbols.lib(.text)
… does not match any input Sections. That line should match all the functions from that library which the main application calls. Either no functions from that library ever get called, or some earlier specification in the linker command file matches those input sections, and caused them to be part of that earlier output section. Try making this entire UNION the first thing in the SECTIONS directive. That would be our first suggestion.
Regarding the diagnostic about directive potentially unsafe … The problem is the asm statement with the .label directive in it. That is a very old way of establishing the load address of an input section. Perhaps this was recommended back when, but now it is done differently. Just get rid of it and rely on LOAD_START, and other related operators, in the linker command file.
Our TI Field Team met in-person with the teams last week.
We wanted to make sure you were aware of these also:
- Typically, we suggest to customers making such a large jump in product versions, to start with a sample project from the highest level version available and build from there. This would mean starting with a skeleton v11 CCS Project (Empty Project) and then incrementally adding the individual source and header files from the older version workspace. If this could be attempted, it might mitigate some of the build errors and warnings you are observing thus far.
- Alternatively, a user could sequentially update from each version in order, in this case, going from v3.3 to V4. Then verify a Build All successfully. Then proceed from v4 to v5 and so on.
- Is any original HW+SW system setup available? In other words, does anyone from the team have access to an original PC/workstation with the v3.3 SW installed?
- Finally, to cast an even broader net outside of just the TI community, it might be appropriate to start an E2E inquiry on this topic? Here is an example:
Please let us know your thoughts as we continue to discuss together.
[CUSTOMER]
Thanks you very much for your prompt reply , we need your assistance on below topic from previous mail chain.
Referring to the email dated 18th Oct 2022 regarding the diagnostic about directive potentially unsafe…..
Request you to share some example on “How to convert below snapshot code into single statement using Load_START in linker command file”.
For my curiosity does the single statement using Load_START for “.label _MainSwitch” will cover the remaining
Assembly code from line 1417 to 1425, If not then how we can link Assembly code from line 1417 to 1425 to Load_START.
Below is the snapshot of Section assigned for “Flash28Funcs”
Please let me know if know any other information.
[TI] So we presume the function Class_FlashUpdate::MainSwitch is the only one in the input section Flash28Funcs. In that case, comment out the .label line and write this in the linker command file …
Flash28Funcs : > FLASHA_1, LOAD_START(_MainSwitch), PAGE = 0
That does the same thing.
Note this presumes there is code elsewhere that uses the symbol _MainSwitch. It seems that code also needs to know the run address and the length. However, in the original implementation, I cannot see how those details are handled, so I don’t mention them here implicitly.
Speaking more broadly … I think the best long term answer is for a better review of the linker command file. A good place to start is the article Linker Command File Primer.
[CUSTOMER]
We appreciate your support!! So continue on previous mail query, for “Class_FlashUpdate::MainSwitch” there are 18 method kept at location shown in below screenshot.
we tried above method by taking reference to example provided in previous mail i.e. (Necessary commenting of assembly (_MainSwitch) and extern of these new Load start, end and run also done along with copying this section on Ram by necessary method.) and the link you have shared snapshot is attached. But even it did not worked.
One thing we have observed in code review is that all these methods are being involved during(or in) start-up file see snapshot below
Request you to share some expert comments which can help us in resolving this migration issue.
If needed let us know your suitable time so that we can setup a teams meet for further discussion on this topic.
Please let me know if more information required.
As you suggested in 24 Oct 2022 mail in this mail chain, we were worked upon below Approach
“Typically, we suggest to customers making such a large jump in product versions, to start with a sample project from the highest level version available and build from there. This would mean starting with a skeleton v11 CCS Project (Empty Project) and then incrementally adding the individual source and header files from the older version workspace. If this could be attempted, it might mitigate some of the build errors and warnings you are observing thus far.”
We created a new workspace in CCS V11 and incrementally add the file from CCS V3.3 project. We are able to build the code, But We came across the same warning mentioned in previous mail I.e
Also we are trying to figure out the start-up file assembly code, can you please help us out on below
- Please share the assembler directive document for CCS V3.3 IDE, which explains the use of below snapshot assembly code.
We also need the doc or link which explains about “_c_int00”
[TI]
At this point, we believe that it is best to post this on the TI e2e forums, if at all possible.
Part of the reason is that the lead TI compiler engineer we were working with offline on this is out of office now until Nov 21st. On the forums, there will be other people from the TI compiler team that will be answering during that engineer’s absence. We can simply cast a bigger net here.
Are you willing to post a thread to our e2e on this? I would suggest including all data to date.
I also would be willing to post with your permission – without identifying you as the end customer.
Let me know please and thanks for your patience.
-----
TY,
CY
