Dimensionamento de Pilha (Stack) e Heap no FreeRTOS

Erros Comuns, Sintomas em Campo e Boas Práticas Consolidadas

Após anos de uso do FreeRTOS em aplicações industriais, IoT, automotivas e científicas, certos padrões de falha se repetem. O mais perigoso deles é que problemas de stack e heap raramente se manifestam como falhas imediatas. Em geral, surgem como comportamentos “estranhos”, difíceis de reproduzir e frequentemente atribuídos, de forma incorreta, a ruído elétrico ou falhas de hardware.

6.1 Sintomas típicos de erro de stack

Problemas de stack costumam apresentar sinais como:

• Reset aleatório após minutos ou horas de funcionamento
• Travamento apenas quando determinada funcionalidade é ativada
• Comportamento correto em debug, mas falha em release
• Corrupção de variáveis globais aparentemente não relacionadas

Esses sintomas ocorrem porque o overflow de stack sobrescreve áreas adjacentes da RAM, muitas vezes atingindo o heap ou dados de outra task. Sem configCHECK_FOR_STACK_OVERFLOW, o sistema continua rodando até entrar em estado inconsistente.

6.2 Sintomas típicos de erro de heap

Já os problemas de heap se manifestam de forma diferente:

• xTaskCreate() retorna falha
• Filas ou semáforos não são criados
• Sistema funciona inicialmente, mas falha após longos períodos
• Consumo de heap aumenta lentamente ao longo do tempo

Quando há fragmentação ou vazamento, o heap pode ter memória total disponível, mas nenhum bloco contíguo grande o suficiente, o que leva a falhas mesmo com heap aparentemente “livre”.

6.3 Erros conceituais mais comuns

Alguns erros aparecem com frequência quase estatística:

• Assumir que stack é em bytes e não em palavras
• Usar printf extensivamente sem revisar stacks
• Criar e destruir tasks dinamicamente em loop
• Não contabilizar Idle Task e Timer Task
• Ignorar watermark e métricas de heap
• Usar heap_3 sem entender o linker script

Esses erros não são “detalhes”, são erros arquiteturais.

6.4 Boas práticas consolidadas em projetos profissionais

A experiência prática converge para algumas regras simples e eficazes:

• Stack sempre dimensionada por perfil de task
• Heap com margem mínima de 30%
• heap_4 como padrão, heap_5 quando há múltiplas SRAMs
• Criação estática para tudo que for crítico
• Monitoramento contínuo de watermark
• Hooks de erro sempre implementados

Essas práticas transformam o FreeRTOS de um RTOS “sensível” em uma plataforma extremamente robusta e previsível.

6.5 Conclusão técnica

Dimensionar stack e heap no FreeRTOS não é um exercício de tentativa e erro, mas um processo de engenharia que envolve compreensão da arquitetura do microcontrolador, do kernel e do perfil de cada tarefa. Quando feito corretamente, o resultado é um sistema estável, previsível e escalável. Quando feito de forma empírica, os problemas aparecem tarde demais, geralmente em campo.