Difference between revisions of "Psas"
m (Routine set_up_fixed_clock_sources()) |
|||
Line 206: | Line 206: | ||
./stm32cube/stm32f0xx/drivers/include/stm32f0xx_ll_rcc.h:685: * @rmtoll CR HSEBYP 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) | ./stm32cube/stm32f0xx/drivers/include/stm32f0xx_ll_rcc.h:688:__STATIC_INLINE void LL_RCC_HSE_EnableBypass(void) | ||
+ | </pre> | ||
+ | |||
+ | == [[#top|^]] ChibiOS STM32 Clock Register Structure == | ||
+ | |||
+ | In file ChibiOS/os/common/ext/ST/STM32F0xx/stm32f091xc.h . . . | ||
+ | |||
+ | <pre> | ||
+ | 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 | ||
+ | |||
</pre> | </pre> | ||
Revision as of 02:19, 24 August 2025
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
^ 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 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
^ ---- ----- ----- ----- ----- ---- ----- ----- ----- ----- ---- ----- ----- ----- ----- ---- ----- ----- ----- -----
<-- 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 . . .
^ 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: