https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Is-the-SEMC-required-for-involved-in-L1-DCache-Management-and-or/m-p/2122205#M34555 <P>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).</P><P>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&nbsp;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).</P><P>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.</P><P>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:</P><P>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?</P><P>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.</P> Tue, 24 Jun 2025 11:32:19 GMT stefanct 2025-06-24T11:32:19Z https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Is-the-SEMC-required-for-involved-in-L1-DCache-Management-and-or/m-p/2122205#M34555 <P>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).</P><P>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&nbsp;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).</P><P>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.</P><P>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:</P><P>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?</P><P>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.</P> Tue, 24 Jun 2025 11:32:19 GMT https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Is-the-SEMC-required-for-involved-in-L1-DCache-Management-and-or/m-p/2122205#M34555 stefanct 2025-06-24T11:32:19Z https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Is-the-SEMC-required-for-involved-in-L1-DCache-Management-and-or/m-p/2122562#M34557 <P>To disable SEMC you can enable SKIP_SYSCLK_INIT macro. To disable cache on SEMC you need to configure the SEMC as non-cachable on the MPU through BOARD_ConfigMPU().</P> <P>Best regards,<BR />Omar</P> Tue, 24 Jun 2025 22:44:11 GMT https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Is-the-SEMC-required-for-involved-in-L1-DCache-Management-and-or/m-p/2122562#M34557 Omar_Anguiano 2025-06-24T22:44:11Z