This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GEL file about bit operation got broken in CCS 3.3.82.13

When using version 3.3.82.13 of Code Composer studio with a c5561 processor, we have found that using Gel files to write to a bit field through a pointer is unreliable. The values in memory do not match what was specified in the Gel script.
 
This problem did not occur with version 3.1.23.
 
Our investigation showed that this problem was linked to using the COFF format. The problem was not exhibited with DWARF. Unfortunately, we have certain tools which rely on the COFF format which makes us unable to switch to DWARF at this time.
 
The steps to reproduce the problem are:
 
1) Rename lnk.txt to lnk.cmd.
2) Load gel file bit_field_test_setup.gel.
3) Rebuild all.
4) Load Debug/CCS33Issue.out.
5) Use GEL->CCS33_TEST->bit_field_test.
6) Fill the dialog boxes with the suggested values then press execute.
7) Run the program and observe the results.
============
The above issue can be reproduced in 3.3.81.6 simulator. Please take a look. It seems the data change was in other memory locations in stead of the one intended. I suspect it has something to do with int or union. Please take a look at the attached file. Thanks.
  • This appears to be a general CCS related issue rather than anything specific to BIOS.  In hopes of getting your question answered faster, I am going to move this post to the CCS forum.

    Best Regards,

    Dave

  • Can someone look into this case please? I will need to get back to the end customer. Thanks!

  • Hello,

    Thanks for the test case. I ran on a C55xx Rev3.0 CPU Functional Simulator. I see the issue with the COFF output while DWARF looks as expected. You are correct, it all works fine with 3.1. I also confirmed that it works in CCSv4.

    Unfortunately, CCS 3.3 has been deprecated in support so getting a fix for this is unlikely. Any chance the customer is willing to update to v4?

    You also mention that the customer needs to stick with COFF because of certain tools that rely on the format. Could you explain what they do? Because if it is for parsing the symbols of the *.out file for information, I'd suggest that they leverage ofd and cg_xml, which can handle COFF or DWARF output (it is agnostic to the format actually). That way they can switch to DWARF format and continue to use CCS 3.3.

    Thanks

    ki

     

     

     

  • Hello Ki-Soo Lee, thanks for your update and suggestions! I am currently still waiting for customer's confirmation. Please bear with me for a few more days before closing it out.