by Olá pessoal,
Outro dia me deparei com um problema bastante estranho no RL78: uma aplicação estava escrevendo no endereço 0xFC00 e seguintes da flash (bloco 63) de um R5F100AEA (um RL78/G13 de 30 pinos com 64kiB de flash e 4kiB da RAM). Para a minha surpresa, sempre que ocorria a tentativa de escrita na flash (utilizando a biblioteca FSL) a sessão de depuração era encerrada com erro e ao ressetar o microcontrolador a aplicação simplesmente não executava mais!
Inicialmente suspeitei que o código da aplicação pudesse estar sendo apagado da flash (por estar apagando um bloco errado da memória), mas esta possibilidade foi rapidamente afastada pois não havia nenhum problema com o código fonte: havia apenas um comando de apagamento e ele era direcionado ao bloco 63 (endereços 0xFC00 a 0xFFFF).
Após diversas verificações e sessões de depuração percebi que a execução do programa (chamada das funções de apagamento do bloco e escrita de dados) eram executadas corretamente quando feitas através do passo-a-passo do depurador, mas assim que eu clicava em “run” a aplicação falhava (travava) e o depurador E1 perdia contato com o microcontrolador alvo.
Verifiquei também que, estranhamente, haviam dados salvos a partir do endereço 0xFE00 da flash! Isso era especialmente estranho pois eu não havia escrito nada lá! Passei a desconfiar que do meu arquivo de configuração do linker e que algum trecho da aplicação estivesse armazenado naquela área da flash. Novamente não encontrei nada de errado e o map file também não mostrou nenhuma alocação para código ou constantes naquela área.
Resolvi executar uma sessão de simulação para verificar se realmente a aplicação não estava utilizando aquela área de memória e constatei que não: na sessão de depuração todos os 1024 bytes do bloco 63 estavam apagados (0xFF).
Resolvi comentar o caso com o Felipe Torrezan, engenheiro da Renesas no Brasil e após muito divagarmos, comentei sobre os dados/código escritos na flash a partir do endereço 0xFE00 e ele me disse que acreditava que pertenciam ao monitor do E1. Bom, a informação fez muito sentido! Isso explicaria o porquê do código estar presente na sessão de depuração e ausente na sessão de simulação! Explicaria também a perda da comunicação com o microcontrolador alvo, já que o código monitor de comunicação com depurador E1 era apagado!
Uma investigação um pouco mais profunda me conduziu ao documento R20UT1994EJ0100 que detalha a conexão do RL78 ao E1 e os recursos utilizados no MCU. A página 17 deste documento mostra os recursos de memória necessários, a figura abaixo foi retirada daquele documento.
A figura acima e o texto da página 18 do referido documento alertam que os últimos 256 ou 512 bytes do topo da flash devem ser reservados quando se utiliza o depurador (seja o E1,E20 ou TK)!
No meu caso, bastou modificar o código (e o arquivo de configuração do linker) para utilizar a página 62 ao invés da 63 e tudo funcionou perfeitamente!
Então fica o alerta: ao utilizar o RL78 e o depurador, não se esqueça dos recursos de memória utilizados pelo mesmo! Isto inclui 12 bytes da área inicial da flash, 256 ou 512 bytes do topo da flash e até 12 bytes da pilha.