nop delay issue

[曾经怀念]

It may be due to my incorrect MPU configuration, so I added a function to disable the MPU before the RamInit startup file.

```

DisableMPU:

    DSB

    ISB

    LDR  R0, =0xE000ED94

    LDR  R1, =0xFFFFFFF8

    STR  R1, [R0]

    DSB

    ISB

RamInit:

    /* Initialize SRAM ECC */

    LDR  R0, =__RAM_INIT
...

```

Then after I solved the MPU problem, I deleted that function.

something wrong happend, the same delay function, the delay time changed from 2ms to 16ms

BCC_WAIT_FOR_MUL4_CYCLES(624510)

#define BCC_WAIT_FOR_MUL4_CYCLES(cycles) \

          __asm( \

            "movs r0, %[cycles] \n" \

            "0: \n"              \

              "subs r0, #4 \n"   \

              "nop \n"           \

            "bne 0b \n"          \

             :                       \

             : [cycles] "r" (cycles) \

             : "r0", "r1", "cc"      \

          )

I have already compared the MPU/CGM/PLL/SYSTEM CONTROL ... , and they are all consistent.

[lukaszadrapa]

Hi @曾经怀念 

MPU is a module which affects the cache attributes. If you want to make some memory area cache inhibited or cacheable, this must be done by configuration of MPU.

If the execution time is changed in that way, it’s obviously caused by different cache attributes – default MPU attributes when MPU is disabled vs. attributes configured by your application.

So, you need to take this into consideration.

From my experience, it’s better to keep such hard loops in cacheable memory. Here’s the reason why (simplified):

If some loop is placed to non-cacheable memory, it depends on exact address. If the loop fits within one flash line, it will be read from physical flash (which is slow) only first time then then the code will be fetched from flash read buffer. So, the execution time will be fast. If you shift the code, so the loop will be split to two flash lines, the physical flash needs to be read many times due to buffer miss. This will make the execution significantly slower.

So, anytime you add some code to your project, everything may be shifted and it can affect the hard loops.

If you keep this code in cacheable memory, the instruction cache will eliminate most of such effects.

Another option is to keep such loop at defined address which is non-cacheable. The disadvantage is that you need to have such area defined in linker file.

Regards,

Lukas