MSPM0G1507: Is there any introductions about the instructions cycle counts of MSPM0G1507? I check the instructions cycle counts in debug mode by using SYSTICK but they can not match with the information I get from ARM's web site.

Hi Peter,

What the CPU rate you are using? I find the ARM documents, it says below:

So, I want you set the CPU rate as default 32MHz, and then the flash wait state will be zero.

B.R.

Sal

Hi Peter,

One thing need correct here.

Please set CPU run rate smaller than 24MHz for 0 wait state. Maybe you can try 16MHz for simple configuration.

B.R.

Sal

Hi Peter,

Not hear the feedback from you for a while, I will close the thread temporarily.

Feel free to reply the thread if you have further question.

B.R.

Sal

Hi Sal,

Sorry for late feedback. I was tracking this issue in E2E chinese site and didn't get your message. I'm using 80MHz CPU rate. So it seems will take 2 CPU clock cycles for the wait state for every instruction, am I right? If yes, the MULS instruction will totally take 3 CPU clock cycles in theory, but 4 CPU clock cycles in fact. I'm still confused about that. Would you please help to figure out it? Thanks.

Hi Peter,

Peter Li said:

So it seems will take 2 CPU clock cycles for the wait state for every instruction, am I right?

That is correct. It will take 2 more CPU clock for flash wait.

Peter Li said:

the MULS instruction will totally take 3 CPU clock cycles in theory, but 4 CPU clock cycles in fact.

Firstly, we do NOT maintain the bench test on this, so I can not tell whether this test result following the expectation. [I also think CPU clock =3 is more reasonable, but I can not guarantee this.]

Secondly, I am not sure how you take the bench test on this, the MSPM0 device do have a Flash Prefetch/Cache. So maybe you test is not accurate.

I could reccommend antoher test method:

Set the Assembly Code into the SRAM, and run in the SRAM to see whether the CPU clock consumption is 1. It should be zero wait-state when runing in the SRAM.

B.R.

Sal

Hi Sal,

Sad to say, I run the assembly code in SRAM, but the MULS instruction still takes 4 clock cycles.

Hi Peter,

It is weird.

Let me do some test next week.

B.R.

Sal

Hi Sal,

Any updates please?

Hi, Peter

During debug start and stop, debugger will insert some instruction to M0+ core.

Maybe this takes some cycles.

Even if you debug some single-cycle instructions, the result may be 4 systick cycles as well.

Run 20 times mul, systick down count 26 times.

Run 10 times mul, systick down count 16 times.

Run 5 times mul, systick down count 11 times.

For mul-steps debug, it will takes extra 6 systick cycles depending on this test result.

I guess for single step debug, it will take 3 extra systick cycles.

Here is the test demo:

Instruction_MUL_Test_CycleTest_G3507.zip

Hope this guide you well.

Regards,

Helic

Hi Helic,

Thank you for your explanation. It's quite helpful for me. I check my code by single step debug and find that almost all instructions clock cycles(with taking out the 3 extra clock cycles) conform to the information came from ARM's web site, but only the LDR instruction. The LDR instruction sometimes may takes 3 or 5 clock cycles, just as I mark in red at below screenshot.

Here's my test code and please kindly help to figure out it.

instructions_test_demo.zip

Thank you!

Hi, Peter

For the extra 3 or 5 clock, or the multi steps debug using breakpoint and resume function's extra 5 clock cycles,

these phenomena should be caused by debugger, and it will take some time to confirm this.

Regards,

Helic