Atualize o ARM pelo ar

Criaremos uma placa ARM com um modem GSM integrado.
Queremos poder atualizar o firmware do ARM pelo ar.

Existe alguma solução boa, confiável e de código aberto para isso?
Caso contrário, existe um sistema operacional pago com esse recurso?

wireless arm firmware

— hotips
fonte

O ARM é bastante genérico: existem muitos fabricantes que incorporam arquiteturas ARM, e alguns deles podem fornecer esse recurso.

— clabacchio

Uma informação mais específica sobre qual chip / família ARM você está planejando usar seria legal. Muitos, se não todos os microcontroladores Cortex-M, suportam a escrita para piscar a partir do código do usuário. Existem implementações de código-fonte aberto, como o bootloader Maple , leaflabs.com/docs/bootloader.html , e acho que já vi a atualização do firmware através de um link de rádio suportado em algum quadcopter.

— Thorn

Nós não escolheu o dispositivo ARM no momento;)

— hotips

O grande problema das atualizações de firmware é como forçar o chip a entrar no modo de atualização quando houver algo errado com o firmware. Quando você tem acesso ao chip, você pode redefini-lo e forçar um pino de bootload alto, mas como você fará isso pelo ar? A única solução confiável que posso imaginar é ter um segundo chip (não atualizável) que lida com a comunicação básica e pode atualizar o chip principal. Depois de resolver esse problema, o carregamento de inicialização real pode ser tão simples quanto usar (por exemplo) o carregador de inicialização incorporado no chip (por exemplo, os uCs de LPC que conheço todos têm um carregador de inicialização serial).

— Wouter van Ooijen

@ Hernan Isso tornaria possíveis modos sutis de falha, como um chip (de alguma forma executando o código errado) mantendo o outro em redefinição. A única solução realmente confiável é manter as funções em um chip tão simples que você nunca precisará atualizá-las.

— Wouter van Ooijen

Respostas:

Não tenho conhecimento de nenhuma solução pré-fabricada, mas descreverei como o resolvi em um projeto. Não é totalmente 'intransponível', mas não estou ciente de que ela falhou em milhares de atualizações. Para esta aplicação, uma taxa de falha muito baixa ainda seria mais barata do que ter acesso às unidades.

O aplicativo principal possui três tipos de pacotes adicionais adicionados ao seu protocolo de comunicação normal, que inclui detecção de erros e uma estratégia de repetição no topo:

Um comando de atualização de firmware inicial limpa uma área de memória reservada em um SPI Flash externo. Ele retornará um erro se a unidade estiver usando sua bateria de reserva ou se estiver usando energia externa, mas o estado de carga da bateria estiver abaixo de 25%.
Um comando de bloco de gravação aceita um endereço de deslocamento e os dados que são gravados na memória Flash externa em pequenos pedaços. O protocolo de nível superior cuida da detecção de erros e retransmissões. Depois que cada bloco é gravado, ele é lido novamente e verificado antes do reconhecimento do comando.
Um comando de atualização de firmware final inclui o tamanho que o firmware recebido deve ter junto com um CRC32 de toda a imagem para verificação adicional. Se isso corresponder ao conteúdo da memória Flash externa e as condições de energia ainda estiverem OK, o mesmo comprimento e o CRC32 é transferido para uma área EEPROM junto com um 'número mágico' para indicar que uma atualização de firmware está pendente.
Um loop rígido é executado no aplicativo principal para forçar a reinicialização do watchdog.
O carregador de inicialização (localizado em uma área protegida contra gravação do Flash do ARM) vê o número mágico na EEPROM e mais uma vez verifica o CRC32 da imagem. Se estiver tudo bem, ele transfere a imagem do Flash externo para a área principal do programa do Flash do ARM.
As informações de atualização pendentes são limpas da EEPROM e um loop rígido força outra reinicialização. Desta vez, o carregador de inicialização iniciará o aplicativo principal normalmente.

Embora eu nunca tenha visto a fase de atualização falhar, testar novos lançamentos de firmware antes da implantação é crucial usando esse método. Se uma nova versão não for capaz de se conectar à rede GSM e aceitar futuros comandos de atualização, será necessária uma atualização de firmware no local.

— PeterJ
fonte

Você está executando Linux, RTOS ou bare metal? Se você estiver usando o Debian, poderá tirar uma foto do sistema de arquivos atual, fazer uma atualização via "apt-get" e depois manter ou reverter as alterações, dependendo se funcionou ou não.

— bassê fred
fonte

Temos Linux e nu metal, dependendo da aplicação ;-)

— hotips

Se você possui Linux, pode aproveitar muito dessa infraestrutura. A maneira como estou lidando com atualizações no meu projeto atual é criar arquivos .deb para os aplicativos personalizados e usar o apt-get update para atualizar o sistema. Eu também estou experimentando com btrfs. Esse sistema de arquivos permite tirar instantâneos. Portanto, meu plano é capturar instantaneamente os diretórios desejados, tentar atualizar e, se não funcionar, reverter o instantâneo. Se você usa o bare metal, provavelmente precisará usar a abordagem usual de memória dupla, uma imagem para o código de trabalho mais recente e outra para o código recém-baixado.

— Fred basset