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.

TMS320F28379D: Debug error "Attempted to read past the end of memory at 0xFFFFFFFFFFFFFFFE @Data"

Part Number: TMS320F28379D

Hello,

I am attempting to use CPU2’s CLA but am getting some strange errors when trying to launch a debug session. Once the debug session launches, I get the following error in the debug pane related to CPU2: “_args_main() at args_main.c (an error occurred: Attempted to read past the end of memory at 0xFFFFFFFFFFFFFFFE @Data)”. In addition, if I try to run main within CPU2, most of the variables values resolve to a similar error stating: “Attempted to read past the end of memory…”.

I created a simplified “sandbox project” that implements the CLA on CPU2 which does not give me these errors and seems to run perfectly fine. I have copied the code (main from CPU1, main from CPU2, the .cla file with the task and linker cmd files) from that sandbox project into my current project but still see the error occur. I compared all the project configuration settings and the debug configuration settings of each project and they match. I tried deleting all the workspace and project files and re-building everything but that did not work either. But since the exact same code works on one project but not on the other I do believe it is probably some configuration somewhere? Looking at this post, https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/918298/ccs-tms320f28388d-debug-error-attempted-to-read-past-the-end-of-memory-at-0xfffffffffffffffe-data, I tried changing the debug DWARF version from 3 to 4 and also tried changing the Floating Point Mode from relaxed to strict but neither of those helped and the program couldn’t seem to find the entry point in main.

I am using CCS version “10.2.0.00009”, compiler version “TI v20.2.2.LTS”. I don’t do anything with the .args section or the c_args _symbol. I have attached a screenshot of the error in question. As seen in the screenshot, I tested for a stack overflow by filling the whole stack memory space with 0xA5 and resetting the program. Once I ran the program I could see that the stack was no where near overflowing. Address 0xB004 – pointed at by the mouse – is the actual location of variable ‘platformCoreConfig’ where the window above says it is at 0xFFFFFFF6.

Thanks

  • Hi Braden,

    Your screen shot did not come through.  Can you please resend.  Also, just for debug purposes, can you please close all open memory, register and variable view windows before you connect to the target.  Let us know what you observe. 

    Thanks,

    Krishna

  • Hi Krishna, 

    Attached the screen shot now. I closed out all memory, register and variables windows and re-started the debugger and saw the same results. Also, to provide additional information, if I just run CPU2 I can successfully reach a breakpoint in the CLA and step through the CLA code. But if I try to set a break point or suspend CPU2, I can't read any variables due to the “Attempted to read past the end of memory…” error. My program is set up to trigger the CLA based on eCAP interrupts and I have a test signal fed into the eCAP input pin so the program seems to be successfully toggling the test GPIO pin and reading in the eCAP to trigger the CLA while running but I can't do any debugging due to the memory errors. 

     

  • Braden, 

    Thanks for the feedback.  Are you able to set a BP, single step and do normal debug operations on CPU2 with CLA2 disconnected?  

    Regards,

    Krishna

  • No, I still see the memory errors as shown in the following screenshot. The only way I have been able to see "normal" operation of CPU2 is if I comment out the task within the .cla file.

  • Can you please elaborate on the .cla file.  Do you mean commenting out lines that you have shown in your screen shot?

  • Yeah, if I comment out the Cla1Task1 ISR I can see CPU2 work. But again, I can run the exact same code on another project and see it work fine with that task ISR un-commented so not sure what is going on.

  • Hi Braden,

    Please do a thorough review of your linker command file and see if you have any variables that have strange or unexpected addresses.  Do the same with your map file.   

    Regards,

    Krishna

  • Hi Braden, 

    We have not heard back and assume you have been able to resolve your issue.  We will close this post based on that understanding.  If it is not the case, please feel free to re-open or submit a new post with the information requested.  Regards, Krishna

  • Hi Krishna,

    Sorry for the delay. After doing some additional testing, I've discovered what is breaking the project but I have no idea why.

    The test sandbox project where I saw the CLA run successfully had no additional classes within the project itself (Just classes linked from a custom static library). My other project where I copied the sandbox project contents to which gives the error has a few classes within the project which seems to break the code. I removed all additional classes in the project and saw the CLA code run successfully. I then created a dummy class with an empty constructor and can see that that breaks the code. Even if I don't include the class in main, I get the above errors. Do you have any idea what could cause this issue?

    Thanks,

    Braden

  • Braden,

    Sounds like you have a cut down version of your project that exhibits the problem.  Is that correct?  If so, will you be able to share this project?  Based on your explanation, there is nothing obvious that we can point.  

    If you are still unable to share the code, you may want to look at the disassembly view and step the code in assembly with and without the dummy class to see if you can observe any difference.

    You can also view the resulting map files under the two conditions and see what is different.

    Regards,

    Krishna

  • Yes, I have a cutdown version of my project (with all local classes removed completely) that does not exhibit the problem. Then if I add in a local class with an empty constructor, I can see the issue appear again. It seems as though the compilation of any local class is causing the issue because the issue will appear if I create the empty dummy class and don't even include it in the project. I am not able to share the code but I stepped through the c_init00() in disassembly and have not been able to determine any differences. I also compared the two map files and there are no differences.

    Is it possible that a project could become complex enough that you would see debugger issues like this? Because everything seems to run correctly if I let the programs free run without using the debugger. I have resorted to removing all my local classes and testing the CLA specific code all within main, then will add all my local classes back in and just run the program without the debugger. 

    Thanks,

    Braden

  • Hi Braden,

    We will need some reproducible test case to investigate further. Would this be possible to provide? I am unable to reproduce with the examples I tried here.

    I don't need your actual code. You can strip down as much as possible (actually that makes it even easier for us to investigate). As long as it can reproduce the issue, that is all we need.

    If you wish to share provately, please start a private E2E conversation with me.

    Thanks

    ki