블록 단위로만 지울 수있는 플래시를 사용하여 증분 업데이트를 수행하려면 어떻게해야합니까?


11

대본

장치의 마이크로 컨트롤러를 업데이트하는 새로운 펌웨어로 저비용 IoT 장치를 무선으로 업데이트하고 싶습니다. 마이크로 컨트롤러 메모리는 32k ~ 128k 범위 (모든 센트 수)의 플래시 메모리 입니다. 이 저렴한 메모리에는 한 가지 주요 제한 사항 이 있습니다. 블록 단위로만 지울 수 있습니다.

질문

차등 ( 델타 ) 업데이트를 수행 할 수 없다는 의미 입니까? 항상 전체 컨트롤러 메모리 (또는 적어도 상당한 부분)를 업데이트해야합니까?

모든 것을 플래시해야 할 필요성을 줄이고 가능한 한 완전히 장치를 손상시킬 위험이 있습니다. 무선으로 마이크로 컨트롤러를 플래싱 할 때 기존 전략이 있습니까?


비용이나 가장 낮은 위험률에 더 중요한 것은 무엇입니까?
Bence Kaulics

@BenceKaulics는 둘 사이의 올바른 균형을 찾는 것 같습니다. 결국 벽돌 위험은 또한 (가중) 비용입니다.
Helmar

답변:


8

간단한 대답은 그렇습니다. 높은 안정성을 원할 경우 부트 로더 및 A / B 코드 이미지를 지원하기에 충분한 플래시 블록이 필요합니다. 새 이미지를 활성화하기 전에 전체 내용을 작성하고 확인한 후 재 시도하십시오.

그러나이 있다 비싼 / 신뢰할 수있는 전략은 당신이 오버 헤드를 줄이기 위해 할 수있는 일이있다. OTA 업데이트에 대한 저수준 지원도 장치 펌웨어 또는 OS의 일부로 제공 될 수 있으므로 배우기를 원하지 않는 한 롤업을 피할 수 있습니다. 이 기능은로 설명 될 수 있습니다 FOTA.

코드베이스를 분할하면 증분 업데이트가 가능하며, 부트 로더가 폴백 사용자 코드없이 네트워크 연결을 설정하고 코드를 다운로드하고 확인할 수있는 가장 좋은 경우입니다. 로컬 게이트웨이를 사용하면 저렴한 비용의 엔드 포인트에서이 작업 관리를 위임 할 수 있습니다.

많은 장치들이 소량의 단어 소거 플래시를 가지고 있으며, 이것을 실패하면 전체 블록을 지우지 않고도 비트를 설정할 수 있습니다 . 이 기능은 블록 크기 단위로 업데이트되는 점프 테이블을 조작하고 코드를 연결하는 데 사용할 수 있습니다. 처음에 전체 A / B 코드 공간을 계획 했더라도 코드베이스가 너무 커지면 더 복잡한 체계로 대체해야 할 수도 있습니다.

정교한 무선 펌웨어 솔루션으로 달성 할 수있는 기능을 명확히하기 위해 부트 로더와 잠재적으로 1 차 통신 스택은 남아있는 전체 사용자 응용 프로그램 공간이 다시 플래시되는 동안 상주 상태로 남아있을 수 있습니다. 오버 헤드가 필요하지 않습니다 (특히 블록 파티셔닝이 소프트 한 경우). 통신 스택을 업그레이드해야하는 시나리오에서 다운로드 및 확인 중에 응용 프로그램 코드에 일반적으로 사용되는 영역을 일시적으로 사용할 수 있습니다. 이를 위해서는 SoC에서 약간의 지원이 필요하지만이를 염두에두고 설계된 2 세대 및 3 세대 장치는 이미 존재합니다.


6

모든 것을 플래시해야 할 필요성을 줄이고 가능한 한 완전히 장치를 손상시킬 위험이 있습니다. 무선으로 마이크로 컨트롤러를 플래싱 할 때 기존 전략이 있습니까?

비교적 정적 인 업데이트를 수행하는 코드 외에도 스토리지에 활성 이미지와 백업 이미지라는 두 개의 이미지를 유지해야합니다. 업데이트가 필요할 때마다 백업에서 수행 한 다음 활성화하도록 전환하십시오. 일단 안정되면 이전 백업 이미지를 업데이트하십시오.

이를 염두에두고 두 이미지를 모두 업데이트 할 때웨어 레벨링 알고리즘을 사용할 수 있습니다. 이러한 알고리즘의 코드는 전체 스토리지의 약 10-15 %를 차지할 수 있지만 장치의 수명을 연장하는 데 가치가 있습니다.

웨어 레벨링은 일반적으로 플래시 컨트롤러에 의해 관리되며웨어 레벨링 알고리즘을 사용하여 데이터가 프로그래밍 될 때마다 사용할 물리적 블록을 결정합니다. SSD (Solid-State Drive)웨어 레벨링에는 동적 및 정적의 두 가지 유형이 있습니다. 다이나믹웨어 레벨링은 삭제 된 블록을 풀링하고 다음 쓰기에 대해 가장 낮은 삭제 횟수를 가진 블록을 선택합니다.

반면 정적 마모 레벨링은 전체 소거 횟수가 가장 낮은 대상 블록을 선택하고 필요한 경우 블록을 지우고 블록에 새 데이터를 기록하며 블록 소거 횟수가 a 미만일 때 정적 데이터 블록이 이동되도록합니다. 특정 임계 값. 이러한 추가 데이터 이동 단계는 플래시 컨트롤러의 오버 헤드로 인해 쓰기 성능을 저하시킬 수 있지만 정적 마모 레벨링은 솔리드 스테이트 장치의 수명을 연장하기 위해 동적 마모 레벨링보다 훨씬 효과적입니다.

( Techtarget.com :웨어 레벨링 )


6

Freescale Semiconductor는 Kinetis 마이크로 컨트롤러를위한 강력한 무선 펌웨어 업그레이드 방법을 설명합니다 .

그것은이라고합니다 : 프로그램 플래시 메모리 스왑 .

플래시 메모리 스왑을 사용하는 시스템

스왑을 지원하는 둘 이상의 내부 플래시 블록이있는 장치에서 각 플래시 블록의 메모리 기본 주소를 교환 할 수 있습니다. 따라서 각 플래시 블록의 주소 위치는 장치의 논리 메모리 맵에서 교환됩니다. 재설정 후 내장 플래시 스왑 시스템은 기본적으로 논리 메모리 맵에서 플래시 블록의 위치에 따라 실행할 소프트웨어를 선택합니다. 이를 통해 프로그래밍이 용이 한 코드 백업 시스템이 가능합니다. 다른 블록을 지우거나 프로그래밍하는 동안 한 블록에서 실행할 수 있습니다. Kinetis 디바이스에서 플래시 스왑 시스템은 기존 애플리케이션에서 새로운 애플리케이션으로 전환하는 모든 단계를 모니터링 / 제어합니다. 이러한 단계 중 하나에서 전력 손실이 발생할 경우 안정적인 작동을 보장합니다.

장점

  • 프로그래밍 용이성. 응용 프로그램은 항상 메모리 맵의 하위 블록에서 실행됩니다.
  • 전력 손실 허용.
  • 부트 로더가 필요하지 않습니다. 기본 응용 프로그램 시작이 지연되지 않습니다.
  • 멀티 태스킹 OS에 적합합니다. 최소 응용 프로그램 가동 중지 시간 멀티 태스킹 시스템에서 백그라운드 응용 프로그램이 실행되는 동안 기본 응용 프로그램 작업을 계속 실행하여 새 응용 프로그램 복사본을 업데이트 할 수 있습니다.
  • 코드의 백업 사본. 알려진 작동중인 응용 프로그램으로 되돌릴 수 있습니다.

단점

  • 백업 사본을 저장하는 데 필요한 추가 플래시 메모리 공간.

블록을 업데이트 한 다음 바꿀 수 있습니다.

업데이트 중 메모리 스왑 시각화

링크 된 문서에는 자세한 설명이 있습니다.

더 안전한 펌웨어 업그레이드를 보장하지만 더 많은 플래시 메모리가 필요하므로 확실히 더 많은 비용이 듭니다 . 또한 적용되지 마이크로 컨트롤러의 모든 유형에 대해서만 내부 플래시 블록 스왑을 지원하는 사람들.


2
이것은 훌륭해 보이며 비용 요구 사항과 균형을 맞출 수 있다면 반드시 고려해야 할 솔루션처럼 보입니다. + 1
Helmar
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.