Heap/malloc on ARM core causes corruption and null pointer exceptions on SHARC core

Bit of added info.

My mallocs (ARM core) are getting assigned to addresses in the 0x89000000 range. This corresponds with the following section in ld.apt:

/* ARM Core 0 L3, DMC0 */
MEM_L3 : ORIGIN = 0x89000000, LENGTH = 112M\

On the SHARC 1 core, the memory map shows:

Am I right in thinking this suggests there's an overlap between the ARM and SHARC L3 assignments?

Also, is there a guide somewhere that explains exactly how memory should be adjusted? It appears that in addition to adjusting the memory sizes in the "Heap and Stack Configuration Tool", there also might need to be manual edits to various linker files.

Thanks in advance.

Hi,

Please note that, memory distribution for ARM and SHARC cores handled by individually, please refer the memory partition of each cores from the corresponding processor's Data sheet and app.ld file. Also memory overlap or runtime error indications are available for ARM and SHARC cores.

In order to isolate the issue, we kindly request that you share your example project with us. Please include a screenshot of any error messages you are encountering, along with detailed steps to reproduce the issue. This will help us to assist you further.

Regards,
Santhakumari.K

Thanks - I found that I'd configured the SHARC 1 core LDF (using the config add-in) with more memory than was actually available.

Please can you tell me how to enable the runtime memory error indications you mentioned above?

Hi,

For ARM core >> Please find the attached sample project for handling exceptions in ARM core. A user-defined handler function, "Exception_Handler," is implemented using the adi_rtl_register_dispatched_handler() API. Here we called a recursive function inside the main to simulate a stack overflow exception. When the exception occurs, the exception handler function "Exception_Handler" will be invoked.

For more information on Interrupt IDs for exceptions, please refer to the file "interrupt.h" by navigating to the "#include <runtime\int\interrupt.h>" header file.

Also, We have implemented the same Exception Handler using "adi_int_InstallHandler" API, for more information on Interrupt IDs available for exceptions in "adi_int_InstallHandler" API, please refer to the file "adi_int.h" by navigating to the "#include <services\int\adi_int.h>" header file.

For SHARC core >> CrossCore Embedded Studio has Stack Overflow checks and Heap checks features, It can be enabled by selecting the "Generate code to catch a Stack Overflow (-rtcheck-stack)" and "Link against heap debugging libraries (-rtcheck heap)" options in the Compiler settings under "Run-Time Checks"

Stack Overflow Checks : When enabled, the run-time environment makes use of the SHARC processors circular-buffer mechanism for stack overflow detection: if the stack pointer (I7) advances beyond the limits defined by its corresponding base and length registers, a circular-buffer interrupt (CB7I) occurs and is trapped.

Heap Checks : The debugging version of the heap library checks for leaks, multiple frees of the same pointer, writes beyond the bounds of an allocation, and so on.

For more information regarding "Run-Time Checks", please refer the following CCES help page:
CrossCore® Embedded Studio 2.12.0 > SHARC® Development Tools Documentation > C/C++ Compiler Manual for SHARC® Processors > Compiler > Run-Time Checking

Also, refer the below FAQ link, regarding "How to identify runtime stack overflow detection in CCES":
ez.analog.com/.../how-to-identify-runtime-stack-overflow-detection-in-cces

Hope this helps.

Exception_SC573.zip

Best Regards,
Santhakumari.K

Great info, thank you.