Hi there,


I am developing a project on a S7G2 (R7FS7G27H2A01CBD) custom board interfacing a 800 x 480 display with touch screen. 

Everything seems to works fine until detected sometimes GUIX internal functions ended up providing BSP_CFG_HANDLE_UNRECOVERABLE_ERROR.

I can reproduce the issue stress testing after pressing the same button many many times on a popup (gx_window_execute) that executes a 'gx_window_close' inmediatly after the popup is shown. When the error is triggered, the behaviour is always the same, BSP_CFG_HANDLE_UNRECOVERABLE_ERROR . Here a screenshot of the 'Debug' tab when the error is triggered:

Some context of the project:

- SSP 1.7.5

- Stack allocated to the thread containing GUIX (HMI thread) is sufficient during all times, not surpassing 50% of the total as recommended.

- I am using screen rotation 90 and a sdram to store all the GUIX processing.

- There are other 7 threads running, all of them of higher priority than the HMI one.


As the triggering point of the error seems to be an internal function of GUIX, which I cannot debug, I am out of ideas of how fix this problem.

Any suggestions of what should I be looking at? 


Thanks in advance,



  • Good day, Alex!

    How's it going for you? I found a thread that has similar problem as yours. The poster of this thread found a solution. You may refer to this link:

    I hope that will help you.

    Best regards,
    RenesasRulz Forum Moderator
  • In reply to Sai:

    you say :-

    As the triggering point of the error seems to be an internal function of GUIX, which I cannot debug, I am out of ideas of how fix this problem.

    If you add GUIX source to the project, and re-build it, and use a development/production license you can debug the GUIX code.
  • In reply to Jeremy:

    hi Jeremy,

    thanks for your answer. debugging GUIX will definitely help.

    can you please point me out where to find the GUIX source code?

    I seem to have development/production license but its details show GUIX "source=no":


  • In reply to AV83:

    Add GUIX Source to the GUIX stack :-


    and disable the warning about multiple symbols :-


    Then rebuild the project.

    You license will allow you to view the GUIX source (view = yes)

  • In reply to Sai:

    hi Sai,

    thanks for your answer. I reviewed the post you mentioned but I am not sure of how this is supossed to help.
    the guy got the BSP_CFG_HANDLE_UNRECOVERABLE_ERROR on initialization, and fixed the issue cleaning and re-building. in my case, I get the error message on stress testing the interaction with GUIX during run-time, initialization is always working as expected.
    can you please provide further details on this specific case?

  • A bit of more data to help understanding this issue.

    I recently was aware of the existence of the 'Fault Status' plugin to be able to debug hard faults. I was able to reproduce the issue therefore runtime stopping @ BSP_CFG_HANDLE_UNRECOVERABLE_ERROR. The information shown on this plugin is the following:

    I couldn't find much information on how to deal with the data provided, just only the meaning of the parameters ticked from some Cortex M4 Faults documentation:

    • FORCED[30]: Forced hard fault Indicates escalation of a fault with configurable priority that cannot be handles, either because of priority or because it is disabled.
    • UNALIGNED[8]:  Unaligned access usage fault Set when the processor has made an unaligned memory access. Enable trapping of unaligned accesses by setting CCR.UNALIGN_TRP. Unaligned LDM, STM, LDRD, and STRD instructions always fault irrespective of the setting of UNALIGN_TRP.

    With this information, I kind of understand there was a unaligned memory access causing the fault but, how can I avoid this from happening if the fault always triggered from inside the GUIX framework? Any ideas?

    Also, I couldn't find any information from Renesas mentioning how to enable trapping of unaligned accesses by setting 'CCR.UNALIGN_TRP'. Any help here?


  • In reply to AV83:

    By the looks of things you have already trapped an unaligned access, this will be from one of LDM, STM, LDRD, and STRD instructions which will always cause an unaligned access fault, even if the UNALIGNED bit in the CCR is 0.

    To trap unaligned accesses from instructions that actually support unaligned accesses :-


    as defined in the ARM CMSIS header file core_cm4.h (though this will probably not be what you want to do, as by default the compiler is configured to generate unaligned accesses for the instructions that support it).

    Unaligned faults like this can be caused by unaligned pointers being passed into API calls, thread stack over flows corrupting the contents of the stack of other threads (though there are other causes)

    This apps note provides some info on Cortex M4 exception faults :-
  • In reply to Jeremy:

    Thanks Jeremy for the info.
    Already contacted Renesas support to review the issue as I feel there is little to do in the current code running at the moment. Still waiting for an answer.