No post anterior vê-se como configurar os dois Watchdogs do microcontrolador STM32F.

Porém, é possível saber qual o motivo que causou o reset? O microcontrolador ligou? Foi pressionado o botão de reset? Ou foi algum dos Watchdogs?

A resposta é: sim, é possível determinar a causa do reset.

Para determinar o motivo do reset, basta avaliar o valor lido no registrador RCC_CSR. Os seis bits mais significativos são utilizados para determinar a fonte do reset:

Abaixo segue o código que lê a fonte do reset, limpa o registrador e determina a fonte, executando blocos de acordo. Com isso é possível determinar tomar ações diferenciadas para cada um dos casos. Note que é usada a operação lógica & (E bit-a-bit).

Para obter apenas o motivo do último reset é necessário realizar a limpeza do registrador. Isso é necessário porque quando ocorre um reset, os bits do registrador não são limpados para zero, mas apenas setados para um, fazendo-os acumular cada uma das fontes de reset que ocorreram.

  uint32_t reset_source = 0;

  // Lê a fonte do reset
  reset_source = RCC->CSR;

  // Limpa o registrador
  __HAL_RCC_CLEAR_RESET_FLAGS();

  if (reset_source & RCC_CSR_LPWRRSTF) {
    // 0x80000000 Low-power reset
  }

  if (reset_source & RCC_CSR_WWDGRSTF) {
    // 0x40000000 Window watchdog reset
  }

  if (reset_source & RCC_CSR_IWDGRSTF) {
    // 0x20000000 Independent watchdog reset
  }

  if (reset_source & RCC_CSR_SFTRSTF) {
    // 0x10000000 Software reset
  }

  if (reset_source & RCC_CSR_PORRSTF) {
    // 0x08000000 POR/PDR reset
  }

  if (reset_source & RCC_CSR_PINRSTF) {
    // 0x04000000 Pin reset
  }

Veja abaixo dois casos:

• Quando o debugger grava e inicia o debug do programa, obtém-se o valor 0x14000000, indicando que houve dois resets:
  • Reset por software; e
  • Reset pelo pino.
• Quando o reset é causado ao pressionar o pino de reset, obtém-se o valor 0x04000000.

Conclusão

Portanto, podemos verificar qual a fonte de um reset, ou seja, qual o seu motivo. Dessa forma, podemos determinar se houve um reset por algum Watchdog, pino, energização, etc. Com isso podemos ter uma dica do que pode ter acontecido logo antes do reset.

No post anterior foi visto como configurar o clock do microcontrolador STM32F para rodar a 72 MHz, baseado no cristal externo.

Neste post serão explicados pra que são e como configurar os dois Watchdogs do STM32F (IWDG e WWDG).

O que é um Watchdog

O Watchdog (cão de guarda) é um periférico interno do microcontrolador que serve para identificar mal funcionamento do programa e reiniciar o sistema a partir de um reset.

É preciso recarregar/alimentar (reload/feed) periodicamente o Watchdog para que ele não cause um reset.

Então, quando um programa entra em um laço infinito ou entra em algum estado inconsistente que evita que o Watchdog seja adequadamente recarregado, o sistema vai resetar em um tempo máximo estipulado pela configuração do Watchdog.

IWDG – Independent Watchdog

O IWDG (Watchdog Independente) é chamado assim porque ele utiliza uma fonte de clock independente do clock do sistema.

Para habilitar o IWDG:

• Abra o arquivo IOC do projeto, entrar em “Pinout & Configuration > IWDG” e então habilitá-lo em “Activated”.
• O valor do prescaler (divisor de clock) e o valor de reload (recarregamento) podem ser configurados para se obter um tempo máximo de reset com precisão.
• Note que o clock usado pelo IWDG vem de um oscilador RC interno de 40 kHz, o que pode ser visto em “Clock Configuration”.

O IWDG pode ser recarregado a qualquer momento, independente do valor do seu contador. Ele vai causar um reset quando seu contador chegar até zero.

Com um clock de 40 kHz, prescaler igual a 16 e valor de recarregamento 4095, o IWDG causará um reset em de 1,6 segundos.

T = 16*(4095+1)/40000

Para evitar isso, chamamos a função que reseta o IWDG no fim do laço while(1){…}, o qual demora 1.0 segundo para ser executado:

int main(void) {
  // ...
  while (1)
  {
    // ...

    // Recarrega o IWDG
    HAL_IWDG_Refresh(&hiwdg);

    // ...
  }
   // ...
}

Note que, para poder debugar o microcontrolador com o IWDG ativo, é necessário configurá-lo para que pare a contagem quando o processador pára em um breakpoint.

Na função MX_IWDG_Init() adicione as linhas a seguir:

static void MX_IWDG_Init(void)
{
  // ...

  // Necessário para parar o IWDG quando
  // o programa para em um breakpoint
  __HAL_DBGMCU_FREEZE_IWDG();

  // ...
}

WWDG – Window Watchdog

O WWDG (Watchdog de Janela) é chamado assim porque com ele é possível configurar uma janela de tempo onde ele deve ser recarregado, de forma a não gerar um reset do microcontrolador. Se recarregar antes do tempo ou depois do tempo o reset ocorre.

Em outras palavras, o WWDG pode ser configurado para exigir um tempo mínimo e máximo entre os recarregamentos, causando um reset caso seja recarregado antes do tempo mínimo ou caso não seja recarregado no tempo máximo.

Este Watchdog funciona de forma um pouco diferente:

• Você configura um valor de recarregamento, por exemplo 127 (0x7F) a partir do qual o contador é decrementado. Se o valor do contador é reduzido a 63 (0x3F) ocorre o reset.
• Você também configura um valor de janela, o valor a partir do qual é permitido recarregar o WWDG. Se, quando recarregado, o contador é maior que este valor, o WWDG causa um reset. Se é menor ou igual, o WWDG é recarregado com sucesso, sem gerar um reset.
  • Se você configurar este valor como sendo igual ao valor de recarregamento, o WWDG funciona como um Watchgod normal, sem o tempo mínimo.
• Você pode habilitar a interrução do WWDG, que ocorre quando o o valor do contador é reduzido a 64 (0x40).

Para habilitar o WWDG:

• Abra o arquivo IOC do projeto, entrar em “Pinout & Configuration > WWDG” e então habilitá-lo em “Activated”.
• Configure em “prescaler” o valor do divisor de clock.
• Configure em “window value” o valor da janela (início da janela).
• Configure em “down-counter” o valor do recarregamento (início da contagem).
• Habilite a interrupção do WWDG e, na aba “NVIC Settings” habilite a interrupção.

Com um clock de 72 MHz, portanto 36 MHz em APB1, prescaler igual a 8 e valor de recarregamento igual a 127, o WWDG causará um reset em de 58,2 milissegundos após o o recarregamento anterior.

T₁ = 8*4096*(127-63)/36000000

Com o valor da janela igual a 64, a janela de recarregamento inicia em 57,3 milissegundos após o recarregamento anterior.

T₂ = 8*4096*(127-64)/36000000

Dessa forma há uma janela de tempo de 0,091 milissegundos para que o recarregamento ocorra: depois de T₂ e antes de T₁.

ΔT = T₁-T₂ = 8*4096*(64-63)/36000000

+--------------------------+
| Recarrega          Reset |
| |-------------|----|     |
| T0            T2   T1    |
|                <-->      |
|                Janela    |
+--------------------------+

Para evitar isso, no arquivo main.c (ou em qualquer arquivo) criamos a função HAL_WWDG_EarlyWakeupCallback(), a qual chama a função de reset do WWDG.

Essa função criada é automaticamente chamada pelo tratamento da interrupção do WWDG.

void HAL_WWDG_EarlyWakeupCallback(WWDG_HandleTypeDef *hwwdg) {
  // Recarrega o WWDG
  HAL_WWDG_Refresh(hwwdg);
}

De forma semelhante ao IWDG, para que seja possível debugar o microcontrolador com o WWDG ativo, é necessário configurá-lo para que pare a contagem quando a execução é pausada em um breakpoint.

Na função MX_WWDG_Init() adicione as linhas a seguir:

static void MX_WWDG_Init(void)
{
  // ...

  // Necessário para parar o WWDG quando
  // o programa para em um breakpoint
  __HAL_DBGMCU_FREEZE_WWDG();

  // ...
}

Por que dois Watchdogs?

Você pode se perguntar porque seriam necessários dois Watchdogs?

Caso o clock principal do sistema falhe, o que pode acontecer por exemplo escrevendo indevidamente em certos registradores, o WWDG vai parar de contar e, portanto, não causará reset. Nesse caso o IWDG entrará em ação, reiniciando o microcontrolador.

Além disso, como foi feito neste exemplo, ambos podem cuidar de dois escopos diferentes:

• IWDG pode ser recarregado a cada 1 segundo, garantindo que o laço de execução principal está sendo executado; e
• WWDG pode ser recarregado pela sua interrupção, garantindo que as interrupções não ficam desabilitadas por períodos muito longos.

Conclusão

Assim, com o uso de ambos os Watchdogs do STM32F, podemos obter uma garantia de que o programa está operando de forma correta: executando todas as suas tarefas e mantendo interrupções habilitadas.

No post anterior foi explicado como configurar um projeto no STM32CubeIDE e debugar o microcontrolador STM32F usando o debugger ST-LINK V2.

Neste post será visto como configurar o clock do microcontrolador para rodar com uma frequência de 72 MHz, utilizando o cristal de 8MHz que vem na placa de desenvolvimento. Na foto este cristal está logo à direita do microcontrolador.

Por padrão o clock do microcontrolador STM32F vem de um oscilador RC interno de 8MHz, calibrado em fábrica. Porém, de acordo com o datasheet, sua frequência pode variar até 2,5 %, o que facilmente se torna problemático em sistemas que fazem uso de comunicação ou de alguma outra forma dependem da precisão do tempo.

Um cristal, por sua vez possui uma variação muito menor na frequência de operação, por exemplo 100 ppm, ou seja, 0,01 %.

Configurando o clock para 72 MHz

Para habilitar e configurar o cristal oscilador:

• Abra o arquivo IOC do projeto.
• Habilite o cristal: entre em “Pinout & Configuration > System Core > RCC” e habilite o cristal “Crystal/Ceramic Resonator”.
  • Se necessário, ajuste a tensão de operação, que neste caso é 3,3 V.
• Configure o clock: entre em “Clock Configuration” e ajuste:
  • “PLL Source Mux” para HSE.
  • “PLL Mul” para x9 (multiplica 8 MHz do cristal por 9).
  • “System Clock Mux” para PLLCLK.
  • “APB1 Prescaler para /2 (divide o clock de 72 MHz por 2).
• Caso alguma configuração do clock estiver inadequada (fora da especificação do fabricante), os pontos onde há erros são destacados pela interface gráfica.
• Agora basta salvar e confirmar que quer gerar o código.

Comparando os clocks de 8 MHz e de 72 MHz

Para comparar o clock anterior com o atual, pode-se usar o bloco de código abaixo, colocado logo antes do laço while(1){…}.

  // Conta quanto incrementos faz em 1 segundo
  // Clock 72 MHz: Cristal externo
  {
    uint32_t wait = 1000; // 1 segundo
    uint32_t count = 0;
    uint32_t tickstart = HAL_GetTick();

    while ((HAL_GetTick() - tickstart) < wait)
    {
        count++;
    }

    count = 0;
  }

Este código conta quantas vezes a variável count é incrementada enquanto se espera o delay de 1 segundo. O código foi adaptado da função HAL_Delay().

Executando para cada uma das configurações temos o seguinte resultado:

Dessa forma, rodando a 72 MHz o contador é incrementado 6.9 vezes mais rápido do que quando rodando a 8 MHz. Revelando um ganho em velocidade, porém menor do que as 9.0 vezes que o clock foi acelerado.

Conclusão

Dessa forma, configurando o clock em 72 MHz usando o cristal externo de 8 MHz, podemos acelerar o processamento e aumentar a precisão temporal do microcontrolador.

Portanto, podemos fazer o LED piscar com mais precisão e fazer mais trabalho entre cada uma das piscadas.

Esta semana chegou em minhas mãos uma pequena placa de desenvolvimento e o seu gravador.

Esta placa possui o microcontrolador STM32F103C8T6, um ARM Cortex-M3 que roda em até 72 MHz, com 64 kB de flash (programa), 20 kB de RAM (variáveis) e diversas interfaces de comunicação.

Criando um projeto

Para programar vamos usar a STM32CubeIDE, uma IDE focada em microcontroladores fornecida pela STM. Vamos criar o projeto:

• Crie o projeto
  • Menu File > New > STM32 Project.
  • Menu Arquivo > Novo > Projeto STM 32.
• Em “Part Number” (à esquerda) digite o código do microcontrolador: STM32F103C8. Selecione na lista e avance (Next).
• Dê um nome ao projeto: Blink (piscar). Finalize (Finish).
• Abrirá este arquivo Blink.ioc, que contém as configurações do microcontrolador para geração automática do código do hardware.
• Configure a interface de debug: à esquerda entre em SYS, selecione “Serial Wire” em Debug e selecione “SysTick” em Timebase Source (fonte de temporização). Note que dois pinos são marcados em verde, pois são usados pela interface de debug.
• Na placa, o LED é indicado como PC13, então configuramos este como saída (GPIO_Output).
• Agora basta salvar e confirmar que deseja gerar o código.

Programando para o LED piscar

Para fazer o LED piscar é muito simples. Usamos duas funções:

• HAL_GPIO_WritePin(), para alterar o valor o IO que controla o LED; e
• HAL_Delay(), para aguardar o tempo passar.

O arquivo com a função main() se encontra em Core/Src/main.c. Este é um dos arquivos gerados automaticamente pela IDE.

Note que você pode modificar o código entre os comentários de início (USER CODE BEGIN XXX) e fim (USER CODE END XXX).

A IDE usa estes comentários para saber onde inserir o código gerado automaticamente. O que estiver fora das regiões permitidas será eliminado na próxima vez que o arquivo Blink.ioc for editado e o código for gerado novamente.

Encontre o laço infinito [while(1){…}] e adicione as chamadas de função para aguardar (delay) e escrever no pino (write pin).

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    // Desligar LED
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);
    HAL_Delay(500);

    // Ligar LED
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);
    HAL_Delay(500);

    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

Configurando o debug

Para configurar o debug basta seguir os passos abaixo:

• Primeiro é necessário compilar o projeto.
  • Menu Project > Build Project
  • Menu Projeto > Compilar Projeto
• Abra as configurações de debug
  • Menu Run > Debug Configurations…
  • Menu Executar > Configurações de Debug/Depuração…
• Selecione a opção “STM32 Cortex-M C/C++ Application”, clique nela com o botão contrário e crie uma nova configuração (New Configuration).
• A configuração de debug deve se parecer com as duas da imagem. Abas: Main e Debugger.
• Inicie o debugger clicando em “Debug”.
• O programa vai parar no início da função main().
• Então é possível usar:
  • “Step Into (F5)” para prosseguir passo a passo, entrando nas funções chamadas;
  • “Step Over (F6)” para prosseguir passo a passo, sem entrar nas funções chamadas;
  • “Step Return (F7)” para parar no retorno da função atual; e
  • “Resume (F8)” para continuar, parando no próximo breakpoint.
• Para criar breakpoints basta dar um clique duplo no número da linha.

Conclusão

Agora é só se divertir com a placa de desenvolvimento: configure os pinos como entrada ou saída, escreva e leia eles.