TMS320C28345: "Attempted to read past the end of memory at..."

This is not a SysConfig issue Peter Luong, please ask this to be reassigned. Also there is not a SW product based support (more than PinMux) for this device.

Hi,

Can you share which example are you attempting to run in CCS. Can you also provide the software package from which you obtained the software.

Please provide the toolchain versions for the CCS environment in which the example was last confirmed to work. Thanks

Regards,

Ozino

Hello Ozino,

Unfortunately, this is a custom program, not an example. I know that will make it harder to diagnose, but any explanation of these errors or what type of things cause them would be appreciated. 

It last compiled and ran with CCS 4.2.4.00033, and the tools included with that. (Looks like it was DSP/BIOS 5.41.10.36) I have followed the migration guide and made many changes to enable it to compile in the new tools listed above.

Thank you.

Hi Nathan, 

Please send us a testcase so that we can duplicate the issue here.  It will help us expedite a resolution to the issue you are experiencing. 

Thanks,

Krishna 

I'm sorry, I cannot share the software.

What parts should I look at when trying to solve these errors? What causes it to read past the end of memory?

Nathan, 

Ok I understand...we try to make some progress but if we cannot duplicate your issue then we cannot route it to the right expertise to help get it resolved.  We may still request you create a simplified version of the project and share it with us, if we do not get anywhere with the next steps.

So first, please close all open memory, variable view and register windows.  Do you still the issue?  

Thanks,
Krishna   

The behavior does not seem to change after closing all variable and memory status windows. It hits a breakpoint, and even when manually resumed, does not seem to run correctly.

Where is it when it hits the breakpoint? In your code? In SYS/BIOS code? If you look at the Disassembly window is it sitting at an ESTOP0?

Is that the Variables view or the Expressions view in CCS in your screen shot? Are they local variables? If you look at your .map file do you see any functions or variables being placed at weird invalid addresses?

Whitney

• The breakpoint seems to occur in my code.
• The errors in my screenshot are from the Variables window, when "main() at sys_manager.cpp:540 0x0131E4" is selected in the Debug window.
• This is what the disassembly window shows when the same thing is selected:
• 
• The variables listed are all local variables, from that same file.
• In a quick look at the .map file, the end looks a little strange, like .text didn't get an address?

1     00017b3b  _ti_sysbios_family_c28_Hwi_interruptReturn__I                                                                                        
1     00017b3c  ___default_new_handler__Fv                                                                                                           
1     00017b3d  __system_post_cinit                                                                                                                  
1     003f7ff8  _CsmPwl                                                                                                                              
abs   00000001  _xdc_rov_runtime_Mon__checksum                                                                                                       
abs   00000001  _xdc_rov_runtime_Mon__write                                                                                                          
abs   00000001  _xdc_runtime_Startup__EXECFXN__C                                                                                                     
abs   00000001  _xdc_runtime_Startup__RESETFXN__C                                                                                                    
abs   000007fe  __STACK_SIZE                                                                                                                         
abs   ffffffff  .text                                                                                                                                
abs   ffffffff  ___TI_pprof_out_hndl                                                                                                                 
abs   ffffffff  ___TI_prof_data_size                                                                                                                 
abs   ffffffff  ___TI_prof_data_start                                                                                                                
abs   ffffffff  ___binit__                                                                                                                           
abs   ffffffff  ___c_args__                                                                                                                          
abs   ffffffff  ___etext__                                                                                                                           
abs   ffffffff  ___text__                                                                                                                            
abs   ffffffff  binit                                                                                                                                
abs   ffffffff  etext  

Thanks for the additional info. Depending on your debugger settings, CCS can try to put a breakpoint at the start of main() after loading the application. Is that not the start of main() though?

With those being local variables, they should just be on the stack. Is your stack similarly weirdly placed in the .map file or is it at a normal address? Where does your linker command file say to place .text? Are you getting any linker warnings?

Whitney

Hi Whitney,

Good morning, thank you for getting back to me.

• Yes, now that you mention it, it does look like the breakpoint is at the beginning of main.
  • How do I disable that breakpoint?
• The stack is listed in the "Section Allocation Map" part of the .map file like this:

.stack     1    00000002    000007fe     UNINITIALIZED

                  00000002    000007fe     --HOLE--

I allocated the entire M01SARAM block to the stack. I don't know why it is listed as starting at 00002. In my .cfg I have it set to: "Program.stack = 0x7fe" which I thought was the correct size for that entire SARAM block.

• I have the .text set to be split across the LSRAM:

.text               : >> L03SARAM | L47SARAM           PAGE = 1

Is any of this obviously wrong?

In the debug perspective in CCS you can go to Tools -> Debugger Options -> Auto Run and Launch Options, you'll see auto run options where you can configure CCS to auto run to the start of main() and halt there on certain events. There are also some other halt options in the Program/Memory Load Options section.

That stack location is fine. I suspect the 2 words at the start of M01SARAM are the code start branch placed at the SARAM boot entry point to branch to the application.

Your .text placement looks fine in your cmd file too, and despite the weirdness in your map file, this does appear to be where your code is executing from in your screen shot--I assume 0x131e4 is within L47SARAM.

Whitney

Hi Whitney,

Thank you for the explanation, so it seems like the breakpoint wasn't important.

Even when I resume, or change the options, the code is not working correctly. Sometimes when I pause I can see the same sort of "read past the end of memory" errors in the variable window. What causes local variables (type: unsigned int) to overflow the stack like this? Is the stack full?

You can look at the value of the SP in the Registers view under Core Registers to see if it has gotten corrupted somehow. It's only a 16-bit register so whatever value is in there it won't resemble what is being shown as the address of those variables in the expressions window.

Do you have optimization turned on in your compiler settings?

Let me loop in someone from the CCS team and see if they can point us to what could cause this kind of error in the Variables view...

Whitney

If I pause execution at random points, the SP often equals 0xE5B2 (though sometimes is a lower, more reasonable value) Does that value mean anything?

Currently optimization is off. Why do you ask?

Thank you for your help.

I had forgotten that this is a SYS/BIOS project--I think the Task stacks may be located at a different location than the system stack which may explain why you're seeing an address outside of  M0/M1 RAM. Is the code executing in a task context when you halt it and the SP is in that 0xE5B2 range? I think if you look for "taskStackSection" in your .map file to see if that's a valid location.

Can you open ROV and see if it is reporting any errors?

I was asking about optimization since sometimes variables will be optimized out and won't show up in the Expressions view, but I don't think that's relevant in the Variables view.

Can you elaborate on how the application itself isn't running correctly? After BIOS_start() does it start successfully executing your Hwis and Tasks? Is it crashing? I agree there's something strange going on with the Variables view in CCS, but maybe there's some other clue in the way the code is behaving that could lead us to a solution.

Whitney

I have seen similar issues reported in the past:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1067914/tms320f28379d-debug-error-attempted-to-read-past-the-end-of-memory-at-0xfffffffffffffffe-data/

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/

The first one sounds more relevant and is also more recent. If I had to guess, it is likely some kind of memory corruption occuring due to some configuration problem. It is hard to know for sure without a test case. I know you cannot share your existing project as is. But would it be possible to strip it down so that you can share it? I just need a very simple stripped down test case that can reproduce the error. Nothing more.

• Yes, it does seem to be in a task context, within the sysbios semaphore class, for example.
• That shows up here in the .map file:

	.ebss      1    00008000    00005ad8     UNINITIALIZED
	                    00008000    00002403     {PROJECT}_p28FP.o28FP (.ebss:taskStackSection)
                        0000a403    00000001     rts2800_fpu32.lib : defs.c.obj (.ebss)

• ROV fails with an error I don't understand.
  •  Error: Failed to start ROV using 'comm=DSLite:0,wsPort=60236':InternalError: Can't find method xdc.rta.Formatter.setOFReader(org.mozilla.javascript.Undefined). (C:/ti/ccs1040/xdctools_3_62_01_15_core/packages/xdc/rov/Model.xs#315)

-I am still attempting to understand what parts of the software are running and why it does not respond to commands. It does not crash, as far as I can tell. It may be stuck in the  semaphore code.

Try ROV Classic instead. There are some FAQs about ROV here that may explain why it isn't working: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/859586/faq-what-is-the-rov-runtime-object-viewer

Whitney

Thank you for pointing me at that. Now I'm uncovering lots of errors.

On launch, I get an event, and see an exception in Task

And after running for around 20 seconds, a huge about of errors suddenly show up in ROV under BIOS - Scan for errors

Does one of these errors look like the core issue, or the first one I should investigate?

Okay, if CCS can't populate the Variables window, it's not really surprising that ROV can't display anything correctly either. Keep trying to use breakpoints and single stepping through the code to try to narrow down where the issue may be.

Does the memory browser work okay? If so, we can try at least check for stack overflow that way. Use the memory fill function in the memory browser to write a pattern (0x5a5a5a5a or something) to the stack and then run the application for a bit so see if the pattern gets entirely wiped out or if it's staying within the appropriate stack memory range.

You may at some point want to create a fresh SYS/BIOS project from one of the examples or templates and start to slowly copy in your code from this project bit by bit if possible. That could be a good way to identify which module is causing things to break...

Whitney

When I use the memory browser to watch the stack, I see the following progress. It does not seem to write past the end of available memory. It does enter a large number of "BEEF".

Start:

After 10 seconds of running:

Also, I am now seeing an error on HeapBuf

Is that not the correct replacement class for a DSP/BIOS BUF in a system with no dynamic allocation/heap? It is defined as a global variable in the .cfg file.

I agree that doesn't look like stack overflow, but it is a bit odd. Not sure where all the BEEFs are coming from. I couldn't find any code in SYS/BIOS that uses a value of 0xBEEF for anything.

I'm admittedly not very familiar with DSP/BIOS, but I did find this porting guide that does seem to confirm that HeapBuf is an appropriate replacement.

Whitney