MSP432E401Y: Hard Fault Address = 0xbebebebe

Peter Hoyer

Part Number: MSP432E401Y

Hi Charles,

I have the problem that although our system is working functionally fine, at some point of time a system exception will occur during load tests. I know, the exception show does not need to be related to where the system has come to crash as other functions may have overwritten memory, I know you have well-written problem solving guides. But given all that, we have done a lot of debugging, code review, heap monitoring, added traps in the those parts of the code which may potentially create complex situations, ... Nothing, all fine.

Below a screenshot of the ROV:

There are not memory overruns within the tasks, the only red one is just closing and in the moment a task exits/deletes, ROV always shows PeakSize = TaskSize. There are no overruns in mailboxes (the overrun itself would not harm but it could show that something is going wrong with a task execution), no Semaphores pending unexpectedly.

There is plenty of heap memory, the only strange thing is the orphan heap with ID 12 which requested 0 bytes and it shown in overrun state. But as the system clock counter is low, this does not seem to be related to the exception to me.

All Hwi interrups result despatched and - not visible here - also on Swi/clock side there is nothing pending.

NDK is fine as well in terms of memory and working sockets.

What caught my attention is the decoded exception message:
Hard Fault: FORCED: BUSFAULT: PRECISERR.Data Access Error. Address = 0xbebebebe

Does 0xbebebebe indicate any specific address or event?

As the task sll shows status "preempted" but it is not waiting for anything (nothing shown pending on the right column), does this mean it has been the last task running before the system entered the exitSpin?

Do you have any other suggestion where to look at or what may cause the exception?

Regards
Peter

over 1 year ago

0 Charles Tsai over 1 year ago

TI__Guru**** 191826 points

Peter Hoyer said:
What caught my attention is the decoded exception message:
Hard Fault: FORCED: BUSFAULT: PRECISERR.Data Access Error. Address = 0xbebebebe

Does 0xbebebebe indicate any specific address or event?

Hi Peter,

I think in this post, Todd explained that the stack is initialized to 0xbebebebe as a method for ROV to find the peak stack size. Can you take a look at this post and see if it helps.

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/741987/ccs-launchxl-cc2640r2-rov-view-stackpeak-and-internal-error

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/819912/rtos-am5748-clock-queue-element-is-0xbebebebe

If you see 0xBEBEBEBE then as per Steve in this post, you have not overflowed the stack yet..

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/148487/how-to-debug-a-stack-overflow

0 Peter Hoyer over 1 year ago in reply to Charles Tsai

Expert 1370 points

Hi Charles,

In the cited post the Hwi status is still fine (exception: none) and it was just an ROV update issue. The address is the same but unfortunately in my case we are definitively beyond, and the system is already in the error loop.

Do you have any other ideas where/how to look?

Regards
Peter

0 Charles Tsai over 1 year ago in reply to Peter Hoyer

TI__Guru**** 191826 points

Hi Peter,

Not sure if you have seen these posts about debugging exception for TI-RTOS projects.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/840835/faq-where-can-i-find-ti-rtos-or-sys-bios-faqs/3109064#3109064

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/953527/faq-ccs-how-can-i-use-system-analyzer-rtos-analyzer-to-debug-a-ti-rtos-sys-bios-application/3523360#3523360

There are a few more FAQ about debugging TI-RTOS in this post.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/840835/faq-where-can-i-find-ti-rtos-or-sys-bios-faqs/3109064#3109064

0 Peter Hoyer over 1 year ago in reply to Charles Tsai

Expert 1370 points

I was lucky with setting my breakpoints and I managed to break just before the system runs into the error loop of the initial question at the beginning of this thread. Unfortunately, the issue does not seem to be related to our code, at least not directly.

It all begins with Memory_alloc being called with the heap handle and the request for 55 bytes:

The functions aligns 55 bytes to 80 and calls Memory_HeapProxy_alloc which – as HeapTrack is enabled – calls HeapTrack_alloc (with one intermediate function step).

This calls once more Memory_alloc:

Through 3 more function steps which you can follow in the second screenshot, we finally get to HeapMem_alloc and here is the surprise: the request for the 80 bytes is being denied.

However there is plenty of heap memory available and in this case the shown values are correct, this is not a malsynched ROV:

There is only default heap configured, for reference the memory map below:

/*
 *  ======== MSP_EXP432E401Y_TIRTOS.cmd ========
 *  Define the memory block start/length for the MSP_EXP432E401Y M4F
 */
--stack_size=2048   /* C stack is also used for ISR stack */
--retain=interruptVectors

HEAPSIZE = 0x28000;  /* Size of heap buffer used by HeapMem */

#define APP_BASE 0x00000000 // 0

MEMORY
{
    FLASH (RX) : origin = APP_BASE, length = 0x000FC000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* Section allocation in memory */

SECTIONS
{
    .text   :   > FLASH
    .const  :   > FLASH
    .rodata :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .TI.ramfunc : {} load=FLASH, run=SRAM, table(BINIT)
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM

    /* Heap buffer used by HeapMem */
    .priheap   : {
        __primary_heap_start__ = .;
        . += HEAPSIZE;
        __primary_heap_end__ = .;
    } > SRAM align 8

    .stack  :   > SRAM (HIGH)
}

What is happening here and why?

Thank you and regards
Peter

0 Charles Tsai over 1 year ago in reply to Peter Hoyer

TI__Guru**** 191826 points

Hi Peter,

Not that I know what went wrong with the heap allocation but I wonder if you use the .cfg to play with the heap size instead of specifying them in the .cmd will make a difference. tirtos_builds_MSP_EXP432E401Y_release_ccs is supposed to be the dependency project by your application project.

0 Charles Tsai over 1 year ago in reply to Charles Tsai

TI__Guru**** 191826 points

Hi Peter,

Not sure if you are able to resolve the issue. I will close the thread for now. If you have any update you can write back to the post and the post will change the status to OPEN again.

Arm-based microcontrollers

Arm-based microcontrollers forum

MSP432E401Y: Hard Fault Address = 0xbebebebe