I am currently battling the clock tree of the RT1021. Since I am using FlexSPI as instruction memory this is a bit complicated as I cannot freely reconfigure the clock tree at will (and I don't want to move the code to SRAM if I can avoid that).
Anyway, in my configuration I don't need the SEMC for anything obvious (there is no SDRAM etc. in use). Therefore I would like to disable it with CLOCK_DisableClock(kCLOCK_Semc) (which is also generated by MCUXpresso in clock_config.c but guarded by ifndef SKIP_SYSCLK_INIT). However, when I do disable it, a call to SCB_InvalidateDCache_by_Addr() (its second DSB instruction to be precise) with an address inside the FlexSPI's range causes the MCU to lock up (i.e., GDB loses connection).
If I do not disable SEMC, the cache invalidation works fine (and it has also worked fine in the past with other clock configurations). I don't think the cache line alignment is a problem here as there is no relevant data near the invalidated address.
Naturally tweaking the clock tree is delicate and this could be just a coincidence but I want to make sure without testing it specifically myself:
Is the SEMC core in the RT102x in any way related to cache management functions outside its own memory range (8000_0000 - DFFF_FFFF) that could explain this behavior?
I take care to not touch the branch in the clock tree feeding the FlexSPI root clock after the bootrom has configured it from FCFB.
