cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H750B-DK Debug issue with SCB_EnableDCache

Al-E-Bags
Senior

Hi all. 

I am aware that this topic has been discussed before here:  https://community.st.com/t5/stm32-mcus-products/debugger-hangs-at-scb-enabledcache/td-p/640648 and here: https://community.st.com/t5/stm32-mcus/dma-is-not-working-on-stm32h7-devices/ta-p/49498 and I seem to have run into the same issue whilst debugging my project.

The project itself is a fairly straighforward TouchGFX generated GUI on the STM32H750B discovery kit which I have imported into CubeIDE for further development.  Thus far I have added USART and SPI peripherals as the H750B must communicate with other MCUs. I'm using CubeIDE Version: 1.16.1 and the project is imported from TouchGFX Version: 4.24.1

I can not be sure whether the addition of these peripherals has generated the problem or, whether the problem is inherent in the undelying architecture but either way, I am perplexed.

The debugger hangs in the following function in core_cm7.h:

__STATIC_FORCEINLINE void SCB_EnableDCache (void)
{
  #if defined (__DCACHE_PRESENT) && (__DCACHE_PRESENT == 1U)
    uint32_t ccsidr;
    uint32_t sets;
    uint32_t ways;

    if (SCB->CCR & SCB_CCR_DC_Msk) return;  /* return if DCache is already enabled */

    SCB->CSSELR = 0U;                       /* select Level 1 data cache */
    __DSB();

    ccsidr = SCB->CCSIDR;

                                            /* invalidate D-Cache */
    sets = (uint32_t)(CCSIDR_SETS(ccsidr));
    do {
      ways = (uint32_t)(CCSIDR_WAYS(ccsidr));
      do {
        SCB->DCISW = (((sets << SCB_DCISW_SET_Pos) & SCB_DCISW_SET_Msk) |
                      ((ways << SCB_DCISW_WAY_Pos) & SCB_DCISW_WAY_Msk)  );
        #if defined ( __CC_ARM )
          __schedule_barrier();
        #endif
      } while (ways-- != 0U);
    } while(sets-- != 0U);
    __DSB();

    SCB->CCR |=  (uint32_t)SCB_CCR_DC_Msk;  /* enable D-Cache */

    __DSB();
    __ISB();
  #endif

The issue is outlined and solutions are offered in the above forum threads however, I'm a way out of my depth here.  My coding knowhow is not sufficient to deal effectively with this problem. 

From reading through the threads, it would appear that converting the inline to a normal function may help (as noted by @Pavel A.).  Would this be as simple as removing the __STATIC_FORCEINLINE prefix from the function? It would seem like a good place to start as the example solutions given look much more in-depth/cmplicated! 

In short, I'm a hobbyist programmer/maker, so this is a shout-out for advice, assistance and support that someone at my level can understand.  Thanks for any suggestions.

   

 

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Pavel A.
Evangelist III

So are you trying to single-step thru SCB_EnableDCache? Then don't, just set a breakpoint and run thru it at full speed. Do not remove __STATIC_FORCEINLINE prefix as this requires editing a library .h file. Add your own normal function, for example void MyEnableDCache() { SCB_EnableDCache(); }  and call that instead. Again, run thru it at full speed.

 

View solution in original post

3 REPLIES 3
Pavel A.
Evangelist III

So are you trying to single-step thru SCB_EnableDCache? Then don't, just set a breakpoint and run thru it at full speed. Do not remove __STATIC_FORCEINLINE prefix as this requires editing a library .h file. Add your own normal function, for example void MyEnableDCache() { SCB_EnableDCache(); }  and call that instead. Again, run thru it at full speed.

 

Thanks for the quick response and your good, helpful advice.  I'll be sure to follow your suggestion in the morning.  My head hurts right now!  I'll update you with my progress in due course:)

Thanks for your help on this issue.  I followed your advice and I'll steer clear of the step through SCB_EnableDCache in the debugger in future. I just wasn't sure if I had inadvertantly generated this problem myself by adding peripherals...possibly incorrectly.