Psas
Portland State Aerospace Society
2025 Q3
Electromechanical Recovery System
^ Kicad
Link to Kicad installation instructions page.
^ ERS board TODO
[ ] create board files for ERS board as of LV3.1-recovery
[ ] add device tree code to select and to enable MCU debug UART
[ ] add a DTS compatible type or entity to group GPIOs together in primary ERS dts file
^ Bindings files and Zephyr
Newer way of doing things with GPIO properties, Zephyr 4.2.0 . . .
- "./dts/bindings/pinctrl/nxp,s32k3-pinctrl.yaml" 115 lines
STM32 clock bindings files . . .
- ~/projects/zephyr-project/zephyr/dts/bindings/clock/st,stm32-rcc.yaml
^ Troubleshooting No Sign of Life
Comparing flash invocation ChibiOS versus Zephyr
ChibiOS ERS make file gives:
ted@localhost:~/projects/psas/psas-avionics/lv3.1-recovery/controlSystem/RecoveryBoard/firmware$ make write openocd -f toolchain/oocd.cfg -c "program ./build/recovery-firmware.hex verify reset exit" Open On-Chip Debugger 0.11.0-rc2+dev-00002-g427552c07-dirty (2021-01-30-10:36) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 1000 kHz Info : STLINK V3J8M3B5S1 (API v3) VID:PID 0483:374F Info : Target voltage: 3.323200 Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for stm32f0x.cpu on 3333 Info : Listening on port 3333 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x08000190 msp: 0x20000200 ** Programming Started ** Info : device id = 0x10006442 Info : flash size = 256kbytes ** Programming Finished ** ** Verify Started ** ** Verified OK ** ** Resetting Target ** shutdown command invoked
To flash Zephyr based app using same openocd call gives:
ted@localhost:~/projects/zephyr-project/psas-ers-firmware/samples/hello-world$ openocd -f /home/ted/projects/psas/psas-avionics/lv3.1-recovery/controlSystem/RecoveryBoard/firmware/toolchain/oocd.cfg -c "program ./build/zephyr/zephyr.hex verify reset exit" Open On-Chip Debugger 0.11.0-rc2+dev-00002-g427552c07-dirty (2021-01-30-10:36) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 1000 kHz Info : STLINK V3J8M3B5S1 (API v3) VID:PID 0483:374F Info : Target voltage: 3.312000 Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for stm32f0x.cpu on 3333 Info : Listening on port 3333 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x08000190 msp: 0x20000200 ** Programming Started ** Info : device id = 0x10006442 Info : flash size = 256kbytes ** Programming Finished ** ** Verify Started ** ** Verified OK ** ** Resetting Target ** shutdown command invoked
^ Debugging With openocd
Got a debugging session working. Observe that an RCC HSE clock initialization step is hanging:
ted@localhost:~/projects/zephyr-project/psas-ers-board-bringup/samples/hello-world$ arm-none-eabi-gdb build/zephyr/zephyr.elf
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
. . .
Reading symbols from build/zephyr/zephyr.elf...
(gdb) target extended-remote:3333
Remote debugging using :3333
0x08000b40 in set_up_fixed_clock_sources () at /home/ted/projects/zephyr-project/zephyr/drivers/clock_control/clock_stm32_ll_common.c:645
645 while (LL_RCC_HSE_IsReady() != 1) {
(gdb) bt
#0 0x08000b40 in set_up_fixed_clock_sources () at /home/ted/projects/zephyr-project/zephyr/drivers/clock_control/clock_stm32_ll_common.c:645
#1 stm32_clock_control_init (dev=<optimized out>) at /home/ted/projects/zephyr-project/zephyr/drivers/clock_control/clock_stm32_ll_common.c:819
#2 0x08002f2e in do_device_init (dev=0x80031c8 <__init_malloc_prepare>) at /home/ted/projects/zephyr-project/zephyr/kernel/init.c:333
#3 0x080017fa in z_sys_init_run_level (level=<optimized out>) at /home/ted/projects/zephyr-project/zephyr/kernel/init.c:392
#4 0x0800196e in z_cstart () at /home/ted/projects/zephyr-project/zephyr/kernel/init.c:815
#5 0x080029bc in z_prep_c () at /home/ted/projects/zephyr-project/zephyr/arch/arm/core/cortex_m/prep_c.c:211
#6 0x08000576 in z_arm_reset () at /home/ted/projects/zephyr-project/zephyr/arch/arm/core/cortex_m/reset.S:207
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit
A debugging session is active.
Inferior 1 [Remote target] will be detached.
Quit anyway? (y or n) y
Detaching from program: /home/ted/projects/zephyr-project/psas-ers-board-bringup/samples/hello-world/build/zephyr/zephyr.elf, Remote target
[Inferior 1 (Remote target) detached]
Need to understand why the bit which `LL_RCC_HSE_IsReady()` checks is never being set.
Some forum posts:
(1) https://github.com/zephyrproject-rtos/zephyr/issues/36524
(2) https://lists.zephyrproject.org/g/users/topic/stm32h753_stuck_on_hse_rdy/112297269
An answer in the second forum post refers to Zephyr test suite files:
ted@localhost:~/projects/zephyr-project/zephyr/tests/drivers/clock_control/stm32_clock_configuration$ ls stm32_common_devices boards CMakeLists.txt prj.conf src testcase.yaml ted@localhost:~/projects/zephyr-project/zephyr/tests/drivers/clock_control/stm32_clock_configuration$ ls stm32_common_core boards CMakeLists.txt prj.conf src testcase.yaml ted@localhost:~/projects/zephyr-project/zephyr/tests/drivers/clock_control/stm32_clock_configuration$ ls stm32_common_core/boards clear_clocks.overlay f2_f4_f7_pll_100_hsi_16_ahb_2.overlay hsi_16.overlay pll_32_hse_8.overlay wb_pll_48_msi_4.overlay clear_f0_f1_f3_clocks.overlay f2_f4_f7_pll_64_hse_8.overlay hsi_8.overlay pll_32_hsi_16.overlay wb_pll_64_hse_32.overlay clear_f2_f4_f7_clocks.overlay f2_f4_f7_pll_64_hsi_16.overlay hsi_g0_16_div_2.overlay pll_48_hsi_16.overlay wl_32_hse.overlay clear_msi.overlay hse_24.overlay hsi_g0_16_div_4.overlay pll_48_msi_4.overlay wl_pll_48_hse_32.overlay f0_f3_pll_32_hse_8.overlay hse_32.overlay hsi_g0_16.overlay pll_64_hse_8.overlay f0_f3_pll_32_hsi_8.overlay hse_8_bypass.overlay msi_range11.overlay pll_64_hsi_16.overlay f1_pll_64_hse_8.overlay hse_8.overlay msi_range6.overlay pll_g0_64_hsi_16.overlay f1_pll_64_hsi_8.overlay hse_css.overlay pll_170_hse_24.overlay wb_pll_48_hsi_16.overlay ted@localhost:~/projects/zephyr-project/zephyr/tests/drivers/clock_control/stm32_clock_configuration$
^ STM32 Clock Settings
In STMicro Reference Manual rm0091-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf, some useful information:
(1) chapter 6.2 "Clocks", p. 97 of 1017 states that internal busses AHB and APB can run at up to 48MHz.
(2) On page 126 of 1017 there is mention of "Bit 17 USART2EN" to enable clock to the second on chip USART.
Note (2) relates to peripheral clock enable bits in register RCC_APB1ENR.
Interesting files in zephyr/tests/drivers/clock_config/stm32_clock_configuration/stm32_common_core/boards:
1 /*
2 * Copyright (c) 2022 STMicroelectronics
3 *
4 * SPDX-License-Identifier: Apache-2.0
5 */
6
7 /*
8 * Warning: This overlay performs configuration from clean sheet.
9 * It is assumed that it is applied after clear_clocks.overlay file.
10 */
11
12 &clk_hse {
13 clock-frequency = <DT_FREQ_M(24)>; /* 24MHz clock */
14 status = "okay";
15 };
16
17 &rcc {
18 clocks = <&clk_hse>;
19 clock-frequency = <DT_FREQ_M(24)>;
20 };
~
~
~
"hse_24.overlay" 20L, 389B
Looking at file ``~/projects/zephyr-project/zephyr/drivers/clock_control/clock_stm32_ll_common.c``, routine ``set_up_fixed_clock_sources()``:
Clock control register set up:
ted@localhost:~/projects/zephyr-project/modules/hal/stm32$ grep -nr LL_RCC_HSE_EnableBypass ./* | grep f0 ./stm32cube/stm32f0xx/drivers/src/stm32f0xx_ll_utils.c:449: LL_RCC_HSE_EnableBypass(); ./stm32cube/stm32f0xx/drivers/include/stm32f0xx_ll_rcc.h:685: * @rmtoll CR HSEBYP LL_RCC_HSE_EnableBypass ./stm32cube/stm32f0xx/drivers/include/stm32f0xx_ll_rcc.h:688:__STATIC_INLINE void LL_RCC_HSE_EnableBypass(void)
^ ChibiOS STM32 HAL
ChibiOS clock init code in file ``ChibiOS/os/hal/ports/STM32/STM32F0xx/hal_lld.c``.
ChibiOS STM32 Clock Register Structure
In file ChibiOS/os/common/ext/ST/STM32F0xx/stm32f091xc.h . . .
459 /**
460 * @brief Reset and Clock Control
461 */
462
463 typedef struct
464 {
465 __IO uint32_t CR; /*!< RCC clock control register, Address offset: 0x00 */
466 __IO uint32_t CFGR; /*!< RCC clock configuration register, Address offset: 0x04 */
467 __IO uint32_t CIR; /*!< RCC clock interrupt register, Address offset: 0x08 */
468 __IO uint32_t APB2RSTR; /*!< RCC APB2 peripheral reset register, Address offset: 0x0C */
469 __IO uint32_t APB1RSTR; /*!< RCC APB1 peripheral reset register, Address offset: 0x10 */
470 __IO uint32_t AHBENR; /*!< RCC AHB peripheral clock register, Address offset: 0x14 */
471 __IO uint32_t APB2ENR; /*!< RCC APB2 peripheral clock enable register, Address offset: 0x18 */
472 __IO uint32_t APB1ENR; /*!< RCC APB1 peripheral clock enable register, Address offset: 0x1C */
473 __IO uint32_t BDCR; /*!< RCC Backup domain control register, Address offset: 0x20 */
474 __IO uint32_t CSR; /*!< RCC clock control & status register, Address offset: 0x24 */
475 __IO uint32_t AHBRSTR; /*!< RCC AHB peripheral reset register, Address offset: 0x28 */
476 __IO uint32_t CFGR2; /*!< RCC clock configuration register 2, Address offset: 0x2C */
477 __IO uint32_t CFGR3; /*!< RCC clock configuration register 3, Address offset: 0x30 */
478 __IO uint32_t CR2; /*!< RCC clock control register 2, Address offset: 0x34 */
479 } RCC_TypeDef;
480
ChibiOS target MCU register addresses and bit definitions
STM32F0xx register addrs and bits are often defined in the following way, in file ChibiOS/os/common/ext/ST/STM32F0xx/stm32f030x6.h:
2751 /*****************************************************************************/ 2752 /* */ 2753 /* Reset and Clock Control */ 2754 /* */ 2755 /*****************************************************************************/ 2756 /* 2757 * @brief Specific device feature definitions (not present on all devices in the STM32F0 serie) 2758 */ 2759 2760 /******************** Bit definition for RCC_CR register *******************/ 2761 #define RCC_CR_HSION_Pos (0U) 2762 #define RCC_CR_HSION_Msk (0x1U << RCC_CR_HSION_Pos) /*!< 0x00000001 */ 2763 #define RCC_CR_HSION RCC_CR_HSION_Msk /*!< Internal High Speed clock enable */ 2764 #define RCC_CR_HSIRDY_Pos (1U) 2765 #define RCC_CR_HSIRDY_Msk (0x1U << RCC_CR_HSIRDY_Pos) /*!< 0x00000002 */ 2766 #define RCC_CR_HSIRDY RCC_CR_HSIRDY_Msk /*!< Internal High Speed clock ready flag */ 2767 2768 #define RCC_CR_HSITRIM_Pos (3U) 2769 #define RCC_CR_HSITRIM_Msk (0x1FU << RCC_CR_HSITRIM_Pos) /*!< 0x000000F8 */ 2770 #define RCC_CR_HSITRIM RCC_CR_HSITRIM_Msk /*!< Internal High Speed clock trimming */ 2771 #define RCC_CR_HSITRIM_0 (0x01U << RCC_CR_HSITRIM_Pos) /*!< 0x00000008 */ 2772 #define RCC_CR_HSITRIM_1 (0x02U << RCC_CR_HSITRIM_Pos) /*!< 0x00000010 */ 2773 #define RCC_CR_HSITRIM_2 (0x04U << RCC_CR_HSITRIM_Pos) /*!< 0x00000020 */ 2774 #define RCC_CR_HSITRIM_3 (0x08U << RCC_CR_HSITRIM_Pos) /*!< 0x00000040 */ 2775 #define RCC_CR_HSITRIM_4 (0x10U << RCC_CR_HSITRIM_Pos) /*!< 0x00000080 */
ChibiOS references:
^ ---- ----- ----- ----- ----- ---- ----- ----- ----- ----- ---- ----- ----- ----- ----- ---- ----- ----- ----- -----
<-- local wiki page separator document section -->
^ Systematic Observations
Ok, removing the incorrect &hse_clk node property "hse-bypass" was not enough to overcome the ``while (LL_RCC_HSE_IsReady() != 1)`` run time hanging. Not a programming error per se, but a reflection that we have not configured STM32F091RC clock settings correctly for the PSAS ERS board.
We know that by changing another clock setting -- specifically by disabling &clk_lsi -- we saw through the debugger that start up code got stuck in a different place. (We made this change per a forum post in which an FAE recommended to disable all clocks and then configure just the high speed external (HSE) clock settings. We need a systematic way to track which clock settings we are changing and what effects these changes have. A table may be in order . . .
Zephyr STM32 start code review
Per the backtrace above in section yyy . . .
stm32_clock_control_init()
^ CAN Bus Sample App
- zephyr/samples/drivers/can/babbling/src
File `zephyr/dts/arm/st/f0/stm32f091.dtsi` defines a node named `can1`. Node is disabled in this overlay file.
^ References
STM32F091 reference manual: