• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 85 subscribers
  • Views 743 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

LAUNCHXL-F28379D: Difficulty with Memory Allocation in CCS for TMS320F28379D Project

LAUNCHXL-F28379D: CCS F28379D ITRAP instructions at entry to C2000ware function InitGpio

Thomas Cox
Intellectual 520 points
Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: C2000WARE,

We have a mature application we are porting from a F28335 to F27389D DSP. Wherever possible we are using the C2000ware library for initialization of and access to on-chip and off-chip peripheral devices on the F28379D processor. We are using CCS version 12.4, C200ware version 4.01 and compiler version 22.6. 

I've encountered an apparent problem with the compiler or linker. I've created 2 build configurations, both for debug sessions over JTAG. One configuration uses GPIO assignments in anticipation of use on a proprietary board design for a new product release. The other is used to run the code on LaunchXL-F28379D demo boards we are using to debug the application until the proprietary boards arrive. The only significant difference between the two build configuration is GPIO pin assignments, which will be different between the 2 target boards.

When using the build configuration for the new hardware, the standard C2000ware initialization logic works fine. On the build configuration for a LaunchXL board, 6 ITRAP instructions appear at the entry point to C2000ware function InitGpio, after which the object code that should have been at the entry point appears. I have a screen capture from CCS debug sessions showing disassembly of the InitGpio entry point in the two cases.

I am already using the compiler directive --gen_func_subsections=on in both build configurations. The linker command files for both build configurations is using the Align(8) directive for all Page 0 memory blocks. 

What can be causing this difference, and how might it be resolved?

  • 0
    TI__Guru**** 469391 points

    Hello,

    Thomas Cox said:
    I have a screen capture from CCS debug sessions showing disassembly of the InitGpio entry point in the two cases.

    Can you provide this screenshot?

    Thanks

    ki

  • 0 in reply to Ki
    Intellectual 520 points

    I can't put the software on a public forum. Can I send the screen captures to you in a private message?

  • 0 in reply to Thomas Cox
    TI__Mastermind 36175 points

    Yes, pls share the screenshot of the disassembly in both the cases.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Intellectual 520 points

    I tried inserting the images in a private message. I get the message "The file or URL is not allowed to be inserted". Can you offer instructions for attaching the JPG?

  • 0 in reply to Siddharth Deshpande
    Intellectual 520 points

    That link does not describe how to overcome the error message I described. I have sent a private e-mail message to Sahil Deshpande with the 2 screen capture images attached, as he requested in our TI private message conversation. It has been 4 days, and I have received no reply.

  • 0 in reply to Thomas Cox
    TI__Mastermind 36175 points

    I have responded to your private message , let me know if you are able to attach the files and send it.

    Best Regards

    Siddharth

  • 0 in reply to Thomas Cox
    TI__Mastermind 30185 points

    Hello Thomas,

    I looked at your screenshots, the issue seems to be that for some reason the location of where the InitGpio function is called is different; the memory at that address for the function is set to all 0s, hence the ITRAPs. Have you double-checked that you're running this code on CPU1?

    When you say you have 2 different configurations, are talking about the CCS build configurations that you can select from or 2 different versions of the project itself? If it's the former, have you verified that the map file that gets generated is the same? You can find this in the CPU1_RAM folder (or the name of your build configuration) as <project name>.map.

  • 0 in reply to Omer Amir
    Intellectual 520 points

    The two build configurations for the same application are different enough in terms of included source content that I did not expect the map files to have the same allocations.

    However, based on your request to see the linker cmd files, I took a closer look. The build configuration that produced ITRAP instructions at the start of function InitGpio allocated RAMD0 in PROGRAM_RAM (.text), and the working build configuration did not. I changed the cmd file for the build configuration with the ITRAP problem to use the same RAM allocation for .text as the working build configuration, and the problem went away.

    It seems as though there should have been a linker warning that pointed me to the part of the cmd file that was creating the failure, but that version had no additional build faults or warnings compared to the working build configuration. 

    At any rate, the problem of the inserted ITRAP commands, which may have been because the entry point for function InitGpio was not correct in the link map, has been corrected, and I can continue to debug the application. Thanks for your assistance. 

  • 0 in reply to Thomas Cox
    Intellectual 520 points

    IT'S BAAAACK!  This time I am working with a related program which shares a lot of source with the program for which I first created this e2e thread. Again Disassembly shows a series of ITRAP instructions at the entry point of a C++ function. It is interesting, and may be relevant that the entry point is at address 0X00D000, the start of memory block RAMGS1. The code that should have been at that address starts at location 0x00D008. The link command file specifies Align(4) for all source code object files. This problem went away on my previous case simply because I instructed the link command file NOT to use memory block RAMD0. In the new instance, RAMD0 is also not used, because that seemed to cause problems the first time. Can you suggest what change(s) I might make that would resolve this?  As before, I cannot share source code except in private messages with a representative in the US. So let's open a private message session if you would like source files or screen images of source files. Clearly the issue is NOT resolved. 

  • 0 in reply to Thomas Cox
    TI__Mastermind 30185 points

    Hello Thomas,

    Thomas Cox said:
    So let's open a private message session if you would like source files or screen images of source files.

    Yes, I think it would be best if you can share screenshots so I can see if the issue can be replicated on my side. I've sent you a friend request.

  • 0 in reply to Omer Amir
    Intellectual 520 points

    Omer - I have accepted your friend request. I can send you a screen shot of the ITRAP instructions at the start of a function placed at 0x0D000 by the linker, and a copy of my linker command file. It may be something in my linker command file that is causing the function entry point to be misaligned. Note that changing the start of RAMGS1 from 0x0D000 to 0xD0008 in the linker command file places the entry point correctly. Whether I use ALIGN(4) or ALIGN(8) makes no difference. 

  • 0 in reply to Thomas Cox
    TI__Mastermind 30185 points

    Yes, privately message me the screenshot and if possible the linker command file as well, that way I can try to see if I get a similar issue on my side.

  • 0 in reply to Omer Amir
    Intellectual 520 points

    I have been able to demonstrate to Omer that the project build in CCS version 12.4 and C2000 compiler version 22.4 is capable of assigning an entry point at 0x0D000 but the code that should be at that location shows up in the CCS Disassembly window 8 words later. When executed, the program crashes on the ITRAP instruction at the entry point.  I discovered today that a build of the same project and same build configuration using compiler v20.12 runs correctly in the CCS debugger. However, the problem of an offset entry point when using compiler version 22.4 seems to be intermittent, so I don't know if we can conclude that the bug is in v22.4 but is not in v20.12.

  • 0 in reply to Thomas Cox
    TI__Guru**** 250620 points

    Please put these files in a zip: the linker command file, the map file, and the executable file.  Attach that zip to a private message to me.  To send me a private message, hover your mouse over my screen name or avatar. A box will pop up. Click on Send a private message.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 520 points

    George - Thanks for stepping in to assist us. I have sent a private message with the ZIP file you requested. 

  • 0 in reply to Thomas Cox
    TI__Guru**** 250620 points

    I'm confused.  Because you say ...

    Thomas Cox said:
    the project build in CCS version 12.4 and C2000 compiler version 22.4 is capable of assigning an entry point at 0x0D000 but the code that should be at that location shows up in the CCS Disassembly window 8 words later

    ... I expected to see the problem near address 0x0000d000.  However, in the linker map file I see ...

      RAMGS1                0000d000   00001000  00000000  00001000  RWIX

    The first column is name of the memory range.  The third column is how many words are used in that memory range.  In this case, 0.  That is, nothing is allocated to the memory range RAMGS1 at address 0x0000d000. 

    You also say ...

    Thomas Cox said:
    the program crashes on the ITRAP instruction at the entry point

    According to the map file, this is the entry point ...

    ENTRY POINT SYMBOL: "CsciCodeStart_Asm"  address: 00081e20

    Everything I see at that address appears typical.  Here is the disassembly ...

    00081e20        CsciCodeStart_Asm:
00081e20   0048   LB           0x081e00
00081e21   1e00

    So, I don't see the problem.  What am I missing?

    Thanks and regards,

    -George