STM32F4 - Lectura del conteo del temporizador de propósito general

Estoy usando la biblioteca STM32F4 HAL en una placa de descubrimiento STM32F4 emulada [en QEMU] e intento configurar TIM2 (temporizador de propósito general) y leer su registro de conteo (sin interrupción). Actualmente siempre obtengo 0 cuando intento leer el contador del temporizador con

uint32_t count = __HAL_TIM_GetCounter(&hTim2);

No quiero pasar a usar una interrupción todavía, hasta que este paso funcione. Tomándolo paso a paso.

Así es como configuré el temporizador hasta ahora:

__initialize_hardware.c

__TIM2_CLK_ENABLE(); // Enable the TIM2 clock
// ...
Timer_Init();

temporizador.h

TIM_HandleTypeDef hTim2;

temporizador.c

#include "timer.h"

void Timer_Init(void) {
    hTim2.Instance = TIM2;
    hTim2.Init.Prescaler = 40000;
    hTim2.Init.CounterMode = TIM_COUNTERMODE_UP;
    hTim2.Init.Period = 500;
    hTim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
    HAL_TIM_Base_Init(&hTim2);

    HAL_TIM_Base_Start(&hTim2); // Trying to start the base counter
}

void HAL_TIM_Base_MspInit(TIM_HandleTypeDef* htim_base) {
    if (htim_base->Instance == TIM2) {
        __TIM2_CLK_ENABLE();
    }
}

void HAL_TIM_Base_MspDeInit(TIM_HandleTypeDef* htim_base) {
    if (htim_base->Instance == TIM2) {
        __TIM2_CLK_DISABLE();
    }
}

luego en main.c

int main(int argc, char* argv[]) {
    while (1) {
        uint32_t count = __HAL_TIM_GetCounter(&hTim2);
        trace_printf("%lu\n", count);
    }
}

Siempre obtengo 0 en el conteo anterior, ¿no estoy seguro de por qué? ¿Alguien puede ofrecer algún consejo?

Respuestas (1)

Finalmente he descubierto mi problema. No tenía nada que ver con mi código, sino con el simulador QEMU en el que estaba ejecutando mi código.

Una vez que conecté la placa y ejecuté el código, comencé a obtener los tiempos esperados.

¡No volveré a usar QEMU!

Exactamente. Cuando tienes un tablero como el discovery que cuesta $15, hay pocas razones para simular.
No tenía idea de que QEMU pudiera simular STM32F4 (bueno, mal como resultó). Hay algunas limitaciones descritas en gnuarmeclipse.github.io/qemu. No revisé esa lista, pero si no es una conocida, tal vez valga la pena informarla como un error.
De acuerdo, la única razón por la que simulé fue porque en realidad estaba codificando mientras viajaba al trabajo/casa en el autobús. Pero ahora esos barcos están completamente fuera del agua.
QEMU es principalmente para emular el núcleo Arm. Los periféricos del proveedor generalmente no están implementados. El complemento Eclipse Qemu admite GPIO para algunos micros. Los proveedores podrían implementarlos, pero no parece que lo hagan.