Skip to main content
wb0gaz
Associate III
January 26, 2022
Solved

Need help to understand relationship of USART1 (as a source of interrupts), EXTI (as an enabler of external interrupts), and NVIC. USART1 RXNE=1 with RXNEIE=1 does not cause interrupt.

  • January 26, 2022
  • 13 replies
  • 4189 views

(BACKGROUND) I'm working on small (GCC/C-language) tests of STM32F051 with STM32CubeIde 1.8.0 on STM32F051 target. These tests are being done ---> without HAL, Lower Level drivers, but am using #include "cmsis_gcc.h" to access CPU interrupt enable/disable/status <---, so your patience is appreciated (that is, I don't intend in these tests to involve HAL or Lower Level drivers). RM0091 is my documentation resource.

(PROBLEM) USART1 is configured to cause interrupt (RXNEIE=1) when RXNE=1 (receive character). Settings verified (RXNE becomes 1 when a receive character is accepted, and RXNEIE is 1.) The expected entry to void USART1_IRQHandler(void) is not happening.

(QUESTIONS)

1. Section 11.2.5: "EXTI line 25 is connected to the internal USART1 wakeup event". Is this used to allow USART1 interrupt request to reach the CPU? I am not using sleep or wake up conditions (the CPU is always running.) In this case is "event" same as "interrupt"?

2. RM0091 section 11.2.4 includes an instruction I do not understand: "• Configure the enable and mask bits that control the NVIC IRQ channel mapped to the EXTI so that an interrupt coming from one of the EXTI line can be correctly acknowledged." From what I see in the various examples at the end of RM0091 (however, not in the USART examples in section A.19.12), two important steps are:

NVIC_EnableIRQ();

NVIC_SetPriority();

I do not see any definition of NVIC registers in RM0091. cmsis_gcc.h contains nothing referring to NVIC. I have no other libraries or include files referenced at this point. Is NVIC something I can manipulate with registers like other peripherals?

I believe __enable_irq() is working: __get_PRIMASK() result follows the expected result based on preceding __disable_irq() or __enable_irq().

Thank you for any suggestions, questions or requests for clarifying information.

This topic has been closed for replies.
Best answer by TDK

You may have better luck by generating a project with CubeMX, then deleting everything HAL-related. There isn't much. This will give you a starting point that includes the appropriate CMSIS headers and basic startup functionality.

13 replies

Pavel A.
January 28, 2022

The chain of headers is this, if I understand correctly:

  • Every HAL component header (stm32NN_hal_xxxx.h) includes stm32NNxx.h which is in .../Drivers/CMSIS/Device/ST/STM32NNxx
  • The stm32NNxx.h defines some obligatory CMSIS junk and then includes one of more specific stm32NNMMxx.h - based on symbol STM32NNMMx defined in the project. If no such symbol is defined, compilation error occurs.
  • These specific stm32NNMMxx.h headers are in .../CMSIS/Device/ST/STM32NNxx/Include ; these can be included directly into user code.
  • Each stm32NNMMxx.h then includes core_cmX.h which is ARM-provided header for cortex-M family. They are in .../Drivers/CMSIS/Include. For STM32F0 it is core_cm0plus.h.
  • These core_cmX.h files contain all the CMSIS defined macros for every supported compiler (by inclusion of cmsis_gcc.h, cmsis_armcc.h and so on). This is how we get __enable_irq, __disable_irq, __get_PRIMASK, NVIC, SysTick and so on.

The Cube generator adds include paths to .../Drivers/CMSIS/Device/ST/STM32NNxx/Include and .../Drivers/CMSIS/Include

Another include chain for HAL users begins from stm32NN_hal_def.h - it includes stm32NNxx.h and so on.

For dual core chips such as H7, stm32H7xx.h includes either CM7 or CM4 header, based on CORE_CM7 or CORE_CM4 defined in the project.

-- pa

wb0gaz
wb0gazAuthor
Associate III
January 29, 2022

Pavel A - this is **REALLY** helpful!

I was already wondering how I could organize a set of header files so I could make my application work "portable" (to other tool chain). I do not object to STMCube32IDE, however, my application will need portability to some completely different MCU families (outside of STM32 or ARM); in this case I need to have .h file set I can "take with me" for each target (because in the end, the application source files will be subject to different tool chains.)

In my prior work, there is always only one .h file for whole MCU part number, so tree structure and dependencies left me wondering how I could identify the correct files and the hierarchy of files to support a given MCU type.

Thank you again for the guided tour, it is very good for helping my understanding!

Dave