Page 1 of 2

STM32F446RE demo has a timing issue  Topic is solved

Posted: Wed Jul 18, 2018 7:01 am
by heliochronix
Hello everyone,

As of trunk@12164, the STM32F446RE demo for the NUCLEO64 does not execute timeouts correctly. Compiling and flashing the demo from ChibiOS sources results in a noticeably faster blink rate on the F446RE than the expected 1000ms period. Compared to a simultaneously running STM32F042K6 running the respective demo code from ChibiOS, it is about twice as fast.

Looking at the RCC registers on the F446RE seems to indicate all clock configurations are correct, so I believe there is some issue in how ChibiOS is translating ticks to periods of time. I'm wondering if this was an unintentional side-effect of the recent F4 clock tree changes that have been happening? I'm still trying to figure out how exactly ChibiOS goes about converting between sleep/delay times and system ticks. Any pointers in the right direction would be appreciated!

Thank you in advance!

Re: STM32F446RE demo has a timing issue

Posted: Wed Jul 18, 2018 7:30 am
by Giovanni
Hi,

Moving in bug reports.

Giovanni

Re: STM32F446RE demo has a timing issue

Posted: Wed Jul 18, 2018 6:07 pm
by heliochronix
Hi Giovanni,

Understood! If there's any additional information that I can provide, I'd be happy to help. Like I said, everything hardware-wise seems correct (180MHz from a 8MHz HSE). I suspect when the MCU configuration is parsed to determine clock ticks per ms (or whatever interval it's looking for), it's off by some factor of 2 somewhere.

One thing I note is required for bug reports that I didn't include is compiler.
This was compiled via arm-none-eabi-gcc 8.1.0.

Re: STM32F446RE demo has a timing issue

Posted: Wed Jul 18, 2018 7:28 pm
by Giovanni
Hi,

The F4 port received changes recently regarding timer clocks, it is something in there probably.

Giovanni

Re: STM32F446RE demo has a timing issue

Posted: Thu Jul 19, 2018 9:12 am
by FXCoder
The sense of the STM32_TIMPRE_PRESCALE4 define is inverted in stm32_registry.h it seems..

Code: Select all

Index: stm32_registry.h
===================================================================
--- stm32_registry.h   (revision 12178)
+++ stm32_registry.h   (working copy)
@@ -98,7 +98,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              TRUE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              FALSE
+#define STM32_TIMPRE_PRESCALE4              TRUE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -480,7 +480,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              TRUE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              FALSE
+#define STM32_TIMPRE_PRESCALE4              TRUE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -839,7 +839,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              FALSE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              FALSE
+#define STM32_TIMPRE_PRESCALE4              TRUE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -1217,7 +1217,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             TRUE
 #define STM32_HAS_RCC_CK48MSEL              TRUE
 #define STM32_RCC_CK48MSEL_USES_I2S         TRUE
-#define STM32_TIMPRE_PRESCALE4              TRUE
+#define STM32_TIMPRE_PRESCALE4              FALSE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -1607,7 +1607,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             TRUE
 #define STM32_HAS_RCC_CK48MSEL              TRUE
 #define STM32_RCC_CK48MSEL_USES_I2S         TRUE
-#define STM32_TIMPRE_PRESCALE4              TRUE
+#define STM32_TIMPRE_PRESCALE4              FALSE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -1942,7 +1942,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              FALSE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              TRUE
+#define STM32_TIMPRE_PRESCALE4              FALSE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -2253,7 +2253,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              FALSE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              TRUE
+#define STM32_TIMPRE_PRESCALE4              FALSE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -2534,7 +2534,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              FALSE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              FALSE
+#define STM32_TIMPRE_PRESCALE4              TRUE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88
@@ -2888,7 +2888,7 @@
 #define STM32_HAS_RCC_I2SPLLSRC             FALSE
 #define STM32_HAS_RCC_CK48MSEL              FALSE
 #define STM32_RCC_CK48MSEL_USES_I2S         FALSE
-#define STM32_TIMPRE_PRESCALE4              TRUE
+#define STM32_TIMPRE_PRESCALE4              FALSE
 
 /* ADC attributes.*/
 #define STM32_ADC_HANDLER                   Vector88

Re: STM32F446RE demo has a timing issue

Posted: Sat Jul 21, 2018 10:20 am
by Giovanni
I committed the fixes, should be OK now.

Giovanni

Re: STM32F446RE demo has a timing issue

Posted: Thu Oct 18, 2018 2:54 am
by heliochronix
Hello again Giovanni,

Forgive me for reopening such an old bug report. I did not get back to you in a timely manner after you reported things being fixed, and I hadn't had a chance to test it until late August. Subsequently I failed to reply to this post, so please forgive me.

I wanted to follow up with you and let you know that I've pulled the latest trunk recently and retested the RT-STM32F446RE-NUCLEO64 demo. Unfortunately, it seems whatever the issue was is still persistent. This is as of trunk@12367. The timeouts are still twice as fast as they should be.

To double check myself and make sure I'm not doing something completely off, I am successfully running make in the following folder of ChibiOS trunk@12367:

Code: Select all

demos/STM32/RT-STM32F446RE-NUCLEO64

Then writing the resulting build/ch.hex file using openocd as follows:

Code: Select all

openocd -f openocd.cfg -c "program build/ch.hex verify reset exit"

The configuration file openocd.cfg I am using for openocd is as follows:

Code: Select all

source [find interface/stlink-v2-1.cfg]
source [find target/stm32f4x.cfg]

And the output is as follows:

Code: Select all

% openocd -f openocd.cfg -c "program build/ch.hex verify reset exit"
Open On-Chip Debugger 0.10.0+dev-00523-g2a3b709aa (2018-08-26-09:40)                                                                     
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v27 API v2 SWIM v15 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.229746
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002b8 msp: 0x20000400
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
** Programming Started **
auto erase enabled
Info : device id = 0x10006421
Info : flash size = 512kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000044 msp: 0x20000400
wrote 49152 bytes from file build/ch.hex in 1.387443s (34.596 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000400
verified 42464 bytes in 0.112959s (367.113 KiB/s)
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
shutdown command invoked


Which indicates a successful write and verification.
I don't think I'm doing anything wrong as the same procedure for RT-STM32F042K6-NUCLEO32 works just fine and results in an appropriate 1Hz LED blink.

Re: STM32F446RE demo has a timing issue

Posted: Mon Dec 31, 2018 10:55 am
by Giovanni
bump

Re: STM32F446RE demo has a timing issue

Posted: Mon Dec 31, 2018 2:16 pm
by FXCoder
Hi,
I had a look again over the hal_lld.h etc. for the F4 series.
Can't see any immediate problem with the clock setting.
In fact the RT-STM32F446RE-NUCLEO64 demo project does not set STM32_TIMPRE in mcuconf.h.
So the guard value of STM32_TIMPRE_PCLK is set for STM32_TIMPRE.
Having STM32_TIMPRE_PCLK removes STM32_HAS_RCC_DCKCFGR and special DIVx options from being considered in setting timer clocks
Thus all should be normal...
--
Bob

Re: STM32F446RE demo has a timing issue

Posted: Mon Dec 31, 2018 5:55 pm
by Giovanni
Hi,

I don't have a board to test right now, this will have to wait.

Giovanni