2012-07-01 04:57 AM
Hi, everyone.
Testing STM32F407. Runs it at 168 MHz (5.92 ns cycle), FLASH-> ACR = FLASH_ACR_DCEN | FLASH_ACR_ICEN | FLASH_ACR_PRFTEN | FLASH_ACR_LATENCY_5WS. Outstanding at the PA1 a simple square wave:PM_(RCC->AHB1ENR, RCC_AHB1ENR_GPIOAEN) = 1; // GPIOA clock enabled
PM_(GPIOA->MODER, GPIO_MODER_MODER1_0) = 1; // PA1 - General purpose output mode GPIOA->OSPEEDR |= GPIO_OSPEEDER_OSPEEDR1; // PA1 - 100 MHz High speed while (1) { GPIOA-> BSRR = GPIO_BSRR_BS_1; GPIOA-> BSRR = GPIO_BSRR_BR_1; GPIOA-> BSRR = GPIO_BSRR_BS_1; GPIOA-> BSRR = GPIO_BSRR_BR_1; GPIOA-> BSRR = GPIO_BSRR_BS_1; GPIOA-> BSRR = GPIO_BSRR_BR_1; GPIOA-> BSRR = GPIO_BSRR_BS_1; GPIOA-> BSRR = GPIO_BSRR_BR_1; GPIOA-> BSRR = GPIO_BSRR_BS_1; GPIOA-> BSRR = GPIO_BSRR_BR_1; } Compiled as follows:STR r1, [r0, ♯ 0x18]
STR r2, [r0, ♯ 0x18] STR r1, [r0, ♯ 0x18] STR r2, [r0, ♯ 0x18] STR r1, [r0, ♯ 0x18] STR r2, [r0, ♯ 0x18] STR r1, [r0, ♯ 0x18] STR r2, [r0, ♯ 0x18] STR r1, [r0, ♯ 0x18] STR r2, [r0, ♯ 0x18] B | L1.6 | On the oscilloscope can see this signal (Attachments img) https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/23318/01.png This means that the Branch instruction is actually executed in 3 cycles? I have to debug in Keil stm32f4discovery. At the Branch instruction cycle counter in the Keil (States) increased by 1. In addition, using SysTick and DWT-> CYCCNT, they are also incremented by 1 for instructions Branch. Why is it so? #art-gpio-ahb2012-07-01 06:21 AM
Why is it so?
Perhaps the pipeline stall is charged to the first store, along with whatever cache/prefetch introduces.
2012-07-01 02:12 PM
First check the STM32F407 errata. There's a warning that not all 'F407 parts (especially those on STM3240G boards, mine has no ART) have the ART flash accelerator. Make sure your unit has the right product ID. Without the ART instruction time (assuming no stall writing to AHB) instructions in flash will have a minimum of 5 wait states.
Second, the GPIOs run asynchronous to internal flash. All you are testing for is the bus stall on writing to the AHB bus, not the flash speed. A better test might be to execute a few tens of instructions (no I/O) toggle the GPIO, the run the same code sequence again to generate your ssquare wave. Look at the GPIO specs, all it can do is toggle at 100MHz, slower than flash. Your program stalls waiting for the GPIO to cathc up.2012-07-02 01:48 AM
Hi Jack,
sorry but as I read from your message, all the 'F407 with silicon revision A don't have ART Accelerator??? All the 'F407 that I have are revision A, do you know when revision Z will be available? Best Regards, Alberto2012-07-02 01:33 PM
There is an issue with the prefetch queue at lower voltages on the F2's, but the cache allegedly works. On the F4 A's the prefetch queue doesn't work. Presumably a critical path in there somewhere that didn't find closure.
For availability call your local ST rep or FAE, there is very low participation here.2012-07-04 11:34 AM
> Clive1, Sunday, July 01, 2012 3:21 PM
> Perhaps the pipeline stall is charged to the first store, along with whatever cache / prefetch introduces. Thank you. I use Z revision. I read STM PM0081 Flash memory interface (ART - all for one cycle). I read ARM Processor instruction timings (If branch taken, pipeline reloads (two cycles are added)). I can not understand the branch should be executed in one cycle or up to 3 cycles? > Jack Peacock, Sunday, July 01, 2012 11:12 PM > First check the STM32F407 errata. Thank you. I read STM32F407 errata. > Second, the GPIOs run asynchronous to internal flash. In my opinion it does not matter. GPIO can have a slight delay. But all the instructions should be followed consistently. > A better test might be to execute a few tens of instructions (no I / O) toggle the GPIO I added a 100 x nop I use GPIO to control the run-time. All debugging tools show a cycle for the branch, but actually three cycles. > Look at the GPIO specs, all it can do is toggle at 100MHz 100 MHz are the two switch 1 -> 0 -> 1, ie 168/2 = 84 MHz max.