Modos Operacionais do Processador ARM Cortex-M3

Esse é o quinto artigo da série escrita pelo engenheiro Ismael Lopes da Silva, exclusivamente para o portal Embarcados. Nessa série focarei no Microcontrolador da STMicroelectronics, o MCU STM32F103C8T6, que é um ARM Cortex-M3. Os pré-requisitos para uma boa compreensão dos artigos é ter o domínio da Linguagem C Embedded e conceitos de eletrônica.

Modos Operacionais do Processador ARM Cortex-M3

O Processador ARM Cortex-M3 opera em dois modos diferentes, que são:

• Modo Thread
• Modo Handler

No contexto dos microprocessadores, o modo Thread representa uma ordem de execução, com instruções encadeadas que são desempenhadas uma por vez. O código normal da aplicação sempre é executado em modo Thread. Também conhecido como “Modo de Usuário” ou “User Mode”. Todas as exceções ou interrupções de nossa aplicação rodam em modo Handler.

Outro ponto importante é que o processador sempre inicia, por padrão, em modo Thread. Também sempre que processador encontrar uma exceção do sistema ou qualquer interrupção externa, ele muda seu modo para Handler, para atender à Rotina de Serviço de Interrupção (ISR), associada a essa exceção do sistema ou interrupção.

Em modo Thread há níveis de privilégio de acesso, portanto, dependendo do privilégio podem haver restrições a acesso a Registradores e outros recursos. No mode Handler o privilégio é total, sem restrições. Quando o processador inicia em modo Thread, o nível de privilégio é total. Veremos níveis de privilégios em outro artigo.

Modos de Operação na Prática

Usando o STM32CubeIDE, no mesmo workspace que criamos no artigo 3, então, vamos copiar o projeto “01HelloWorld” como “02ModoProcessador”. Na janela “Projetc Explorer”, clique com o botão direito do mouse sobre o projeto “01HelloWorld” e selecione “Copy”. Novamente na janela “Projetc Explorer”, clique com o botão direito do mouse sobre o projeto “01HelloWorld” e selecione “Paste”. Uma janela para renomear a aplicação será mostrada, portanto, entre como o nome “02ModoProcessador”. Depois clique no botão [Copy].

Fizemos uma cópia porque tudo que preparamos é mantido, então, vamos apenas editar o arquivo main.c e outro que for necessário. Apenas temos que refazer a configuração do depurador, para habilitar o SWV (Serial Wire Viewer), já detalhado em outro artigo.

Como nessa aplicação continuamos usando a função “printf”, então, o processo de depuração precisa captar as mensagens da aplicação, então, temos que manter o uso da janela “SWV ITM Data Console”. Para mais detalhes vejam os arquivos anteriores.

Segue o arquivo main.c editado para mostrar os modos de operação do processador. Os comentários nas linhas do programa também auxiliam no entendimento do código.

Não vou repetir ações que já detalhei em artigos anteriores, portanto, vou somente citar o que deve ser realizado. Obviamente somente novas situações serão detalhadas.

Como temos uma nova aplicação “02ModoProcessador”, novo arquivo main.c, então, vamos dar um “Clean Project”, “Build Project” e ative a perspectiva de depuração. Quando iniciar a depuração (debugging), habilite janela “SWV ITM Data Console”, ative a porta 0, para capturar as mensagens enviadas pelas funções “printf”.

ATENÇÃO! No repositório de recursos dessa série eu adicionei o seguinte documento que vamos utilizá-lo (https://github.com/IsmaelLopesSilva/IoT/blob/master/STM32/STM32F103C8T6/ST%20Docs/STM32F10xxx%20Programming%20Manual%20(PM0056%20-%20DocID15491%20Rev%206).pdf).

Nessa aplicação não exploraremos seu código, porque apenas quero demonstrar os modos de operação do processador ARM Cortex-M3, mas, é uma aplicação simples e seus comentários auxiliam no entendimento prévio, porém, o foco é monitorar um Registrador especial que nos mostrará o modo de operação em cada trecho da aplicação.

Onde Monitorar o Modo de Operação do Processador ARM Cortex-M3?

No documento, ARM Generic User Guide Cortex-M3 (DUI0552A), disponibilizado no repositório do github dessa série, na página 19, encontraremos detalhes sobre o Registrador IPSR (Interrupt Program Status Register). Os nove bits iniciais do IPSR [8:0] compõe o campo chamado ISR_NUMBER (Número da Rotina do Serviço de Interrupção), que são:

• 0 = Thread mode;
• 1 = Reserved;
• 2 = NMI;
• 3 = HardFault;
• 4 = MemManage;
• 5 = BusFault;
• 6 = UsageFault;
• 7-10 = Reserved;
• 11 = SVCall
• ;12 = Reserved for Debug;
• 13 = Reserved;
• 14 = PendSV;
• 15 = SysTick;
• 16 = IRQ0;
• .
• .
• .
• n+15 = IRQ(n-1)^a – O número de interrupções, n, pode ser de 1 à 240.

Se o processador estiver em modo Thread o valor do ISR_NUMBER = 0. Qualquer valor maior do que zero o processador estará em modo Handler. Cada valor do ISR_NUMBER > 0, representa um tipo de exceção ou interrupção, que correntemente está sendo tratada.

Monitorar os Modos Operacionais do Processador na Prática

Com a aplicação está sendo depurada (debugging), na STM32CubeIDE, insira um breakpoint na linha do programa, conforme mostrado a seguir:

Mas, como estamos iniciando a depuração, então, a linha atual de depuração é a seguinte:

Temos que monitorar o Registrador IPSR, portanto, temos que visualizar a janela chamada “Registers”. No menu “Window”, parte superior da tela, selecione “Show View” e “Registers”. A janela “Registers” será mostrada conforme ilustrado na figura 3. Selecione o Registrador “xpsr’, que é o Registrador onde monitoraremos o valor do campo ISR_NUMBER [8:0].

Voltando a depuração, estamos parado na primeira linha da função main.c. Na janela “Registers”, quando selecionamos o Registrador “xpsr” seu conteúdo é mostrado logo abaixo, conforme a seguir:

Os valores são mostrados em vários formatos numéricos, portanto, destaquei apenas o formato binário, que nos mostrará em detalhes o conteúdo do campo ISR_NUMBER. Inicialmente o processador opera em modo Thread, o que é confirmado porque ISR_NUMBER = 0.

1) Agora vamos pressionar a tecla [F5], que é um “step into”, onde caminharemos linha por linha no processo de depuração. Nesse momento focaremos apenas no valor do campo ISR_NUMBER, para acompanhar o modo de operação do processador em cada parte da aplicação.

2) Vamos dar mais um passo, pressionando a tecla [F5]. Entramos na função “gerar_interrupcao”, e continuamos operando em modo Thread.

3) Vamos dar mais um passo, pressionando a tecla [F5]. Continuamos em modo Thread.

4) Vamos dar mais um passo, pressionando a tecla [F5]. Continuamos em modo Thread.

5) Vamos dar mais um passo, pressionando a tecla [F5]. Continuamos em modo Thread.

6) Agora não podemos dar mais um passo usando "step into”, porque o depurador não gatilhará a interrupção de software IRQ3, portanto, como adicionamos o breakpoint dentro da função de tratamento de interrupção “RTC_IRQHandler”, então, para funcionar temos que pressionar a tecla [F8], que faz um “Resume”, sendo assim, a próxima linha gera a interrupção IRQ3 e o programa rodará até o breakpoint normalmente.

ATENÇÃO! O processador foi para o modo Handler, e o campo ISR_NUMBER = 19, que indica que a interrupção IRQ3 foi gatilhada.

7) Agora podemos voltar a dar mais um passo, pressionando a tecla [F5].

ATENÇÃO! O processador voltou para o modo Thread, e o campo ISR_NUMBER = 0. Significa que a rotina de interrupção foi tratada e o programa voltou ao modo Thread.

Podemos interromper a depuração, porque já caminhamos pelos trechos de código que nos interessava.

Para finalizar colocaremos novamente em processo de depuração, e visualizar a saída da janela “SWV ITM Data Console”, e apenas ver as mensagens capturadas. Destaque a janela “SWV ITM Data Console”, “start trace” e pressione a tecla [F8], para resumir a depuração. A depuração rodará até o breakpoint, então, pressione novamente a tecla [F8] para concluir a depuração. Para finalizar interrompa o processo de depuração.

As mensagens capturadas são mostradas a seguir, e podemos confirmar tudo que vimos em detalhes no passo a passo.

• Em modo Thread. Antes da Interrupcao
• Em modo Handler. Tratando a Rotina de Servico de Interrupcao
• Em modo Thread. Depois da Interrupcao