This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex M4 fetch Execute program counter functionning

Note: This was originally posted on 13th May 2013 at http://forums.arm.com

Hello,

I'm new on this forum and I would like to know some details about the execution of a program on a Cortex M4 ( in a STM32F407 microcontroller). I'm looking for this information because of my studies.

These are my questions :

First I would like to know if there is some kind of predictable execution of the code during the fetch & execute step? It 's quickly mentionned in the user manual and I also read some lines about this in the Cortex A documents but I would like to have some explainations.

I would also like to know how is the program counter (R15 register) functionning? There is a real physical counter which count from 0 to -- when a page is loaded from the flash memory (before to add the value with something else and to store that in R15)?  I mean: when I'm reading a page from the flash memory there is a counter which counts 2 by 2 (because of the lengh of the Thumb mnemonics)? If I'm branching far enough to go on another page the counter would return to 0 ? How does it work?

In addition, from a programming point of view, can I choose to write a part of my code at a precise address of the flash memory, and so creating empty areas between 2 parts of code in the flash? Until know I'm writing a lot of "NOP" before to branch....

Finally, all the registers of the Cortex M4 ( R0 to R15 but also the peripheral registers ...) are physicaly situated at the same place? Or the peripheral register are physicaly situated near from the the corresponding peripheral on the chip?

Thank you very much for yours answers and your help!!!!
  • Note: This was originally posted on 14th May 2013 at http://forums.arm.com

    Thank you for your quick answers!

    Do you know how does the predictable execution of the code works? How does the core do to foresee the next code line? Is it different from the more complex µC like the serie of Cortex A..  ?

    About the program counter, how does it work to take the next address? if it were a simple counter it would not work because some mnemonics are longer than others and are coded on more than 2 successive addresses...

    And concerning the possibility to put a part of the code at a precise address of the flash memory, does someone know if it is possible?

    Finally I would like to know if during the reading of the flash memory each page is stored in a buffer before to be treated ?


    thank you!
  • Note: This was originally posted on 14th May 2013 at http://forums.arm.com

    the PC is a 32-bit regeister , it will load the address of the next instruction to be executed and sine it is 32bit  , the pc can locate the 4G memory and physicaly designed to do this not software .there are predictable execution of the codes , but it is physically fixed , it is physically  designed according to the arm core architecture.all the registers of the Cortex M4 is physicaly put together and the perpherial instrument are connected by the AMBA. the M4 I/O ports can reused to be other function ,so if the function is changed then the registers are far away from the perpherial ,so it is clear the registers are set together.
  • Note: This was originally posted on 20th May 2013 at http://forums.arm.com

    the pc and prefetch are all decided by hardware architecture designed by ARM  and have no relationship with software . So prefetch  has some differences between cortex m4 and A series ,they are designed for different use. 

    the buffer is the D/I cache ,all right ? also it is decided by hardware disign , the frequently used data/instruction will be hold in the cache if the cache is full ,then the less used data will be wiped out. the flash is nor/nand flash ? it will be copied into the SRAM ,all the datas processing are in the SRAM ,the buffer is just for high speed data fetch ,just like the prefetch but has different startegy.