Timing problem:
(1) Created a foreground/background loop (ie: while(1)) for a STM32F103RB board designed for a 16MHz XTAL. The loop runs fine on this board. The code framework (ie: timings, etc...) was created using the STM32CUBEMX utility with the Input Frequency in the [ClockConfiguration] tab set for 16MHz. This program has run stably for a week now.
(2) Created an RTX5RTOS2 template program which has 2 tasks and just ping-pongs an LED based on messages received every 1 second. Initially tried to run this project on the same 16MHz board and it Hard Faults with an 'Imprecise bus error' within 10 seconds every time (fault seems to be around an RTOS source-coded task switch function returning NULL at times). I have adjusted [Project][Options] XTAL to 16MHz and selected the #define STM32F10X_MD in the stm32f10x.h header file (BTW: Did not find any **obvious** documentation that this needs to be done when creating a project). I did note that further down this header file (about line 120 in mine) that the HSE value is coded/expected to only be either 8 or 25MHz!?
(3) I then changed the crystal frequency (and project settings) to support an 8 MHz XTAL and ran it up on 2 OLIMEX eval boards (STM32-H103). They have run stably for 5 days. So the application code, as written, is stable.
(4) Physically changed the board with the 16MHz crystal from 16MHz to 8MHz and ran the same code running on the OLIMEX board on the now-modified 8MHz board and it has run stably for a day now.
(5) I have also compared the RCC peripheral registers with the values generated by the STM32CUBE utility against what the RTOS generates with a 16MHz crystal and find them to be equivalent EXCEPT for the RCC->CR register CAL and TRIM bits (which are generated by the chip itself on startup according to ST spec).
I have been working on this specific problem for a little over a week now and have 2 paths to follow: (1) The 16MHz crystal has some sort of stability issue as designed or (2) The RTOS kernal has a problem with a non-standard crystal value.
BUT: If the 16MHz crystal has stability issues then the while(1) code should also fault (which is does not).
Thoughts would be welcome....