boot application - issue with SCB_DisableDCache

[Anand Ram]

does anybody have a idea why the code is stuck at below do while loop (bold marked)?.

use case: for the boot application , SCB_DisableDCache () is getting called before jumping into use aplication.

__STATIC_INLINE void SCB_DisableDCache (void)

{

 #if defined (__DCACHE_PRESENT) && (__DCACHE_PRESENT == 1U)

  uint32_t ccsidr;

  uint32_t sets;

  uint32_t ways;

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

  __DSB();

  SCB->CCR &= ~(uint32_t)SCB_CCR_DC_Msk; /* disable D-Cache */

  __DSB();

  ccsidr = SCB->CCSIDR;

                      /* clean & invalidate D-Cache */

  sets = (uint32_t)(CCSIDR_SETS(ccsidr));

  do {

   ways = (uint32_t)(CCSIDR_WAYS(ccsidr));

   do {

    SCB->DCCISW = (((sets << SCB_DCCISW_SET_Pos) & SCB_DCCISW_SET_Msk) |

            ((ways << SCB_DCCISW_WAY_Pos) & SCB_DCCISW_WAY_Msk) );

    #if defined ( __CC_ARM )

     __schedule_barrier();

    #endif

   } while (ways-- != 0U);

  } while(sets-- != 0U);

  __DSB();

  __ISB();

 #endif

}

[upanie]

Hmm, I have no idea what's going on but today it works fine :\

I didn't have to do any change, just powered up and works like a charm.

Super strange.

[upanie]

Just for the record, I know what was the reason of the super strange behavior.

It was flux. The PCB wasn't super cleaned after soldering and it caused super strange behavior.

The microcontroller was behaving really odd and not only the microcontroller.

External USB phy also was behaving wacky and even DC/DC converter was giving some strange symptoms and sometimes it even stopped working.

After a few sessions in ultrasonic cleaner everything started to work as expected.

[Pavel A.]

> It was flux.

No, not likely. Seen this behavior on several ST eval boards.

When running thru SCB_DisableDCache at full speed, debugger will not hang. Only when single stepping it hangs.

So this is caused either by single-stepping thru an inline function or some specific handling of stuff related to the cache.

Just do not single step thru these functions.

-- pa

[upanie]

In my case flux was guilty for sure. Believe me, I spent loooong days chasing weird problems. Cache issue was only one of many other.

Cleaning board fixed all issues and not only on that one board.

It's Weller flux. It has pretty low resistance and it's not "stable" it depends on temperature and time (probably the time of current flowing through it)! I know it may sound weird but it's true. Right after soldering, when the PCB and flux are warm everything works fine. After it cools down stupid crazy things start to happen.

[mwb]

Hi all,

have the same issue here: ccsidr, sets and ways are local variables of SCB_DisableDCache() that are stored on the stack. ccsidr is only read once before executing the two nested loops. However, the value changes during runtime - which may be due to some stack issue?

Edit #1: This may be related to GCC optimization levels!

See also: https://github.com/ARM-software/CMSIS_5/issues/620

Edit #2: Same problem has been described here: https://community.st.com/s/feed/0D53W00000oVveoSAC - also got the same reference from Edit #1

[heveskar]

Also relevant (same problem): https://community.st.com/t5/stm32-mcus-embedded-software/problems-using-the-cache-and-scb-disabledcache-in-bootloader/m-p/154741