일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 아마존 웹 서비스
- 개발자
- backtest
- Cloud
- Bitcoin
- 오토사
- probability
- 토플 라이팅
- AUTOSAR
- 백트레이더
- 백테스트
- 암호화폐
- it
- 프로그래밍
- 비트코인
- 클라우드
- 자동차sw
- 확률
- TOEFL
- GeorgiaTech
- python
- backtrader
- 파이썬
- can
- AWS
- 자동매매
- toefl writing
- 토플
- 퀀트
- 블록체인
- Today
- Total
Leo's Garage
NvM ReadAll과 WriteAll의 수행 순서 본문
최근에 NvM WriteAll 시에 Garbage Collection 상황에서 특정 Block이 저장되지 않는 이슈가 있었다.
이를 해결하기 위해 코드를 분석하던 중 알아낸 사실에 대해 공유하고자 한다.
기본적으로 내가 사용 중인 AUTOSAR 구현체는 Vector사의 Microsar이다.
따라서 그 외에 업체에서 제공하는 AUTOSAR 구현체가 동일한 형태로 구현되어 있는지는 알지 못한다.
우선 NvM ReadAll의 경우에는 Microsar에서 Dflash에 있는 데이터를 일대일 대응되는 NvM Rte Ram 변수로 가지고 올 때 NvM Index가 작은 쪽에서 큰 쪽으로 순차적으로 가져온다.
그런데 NvM WriteAll의 경우에는 물론 이 경우에는 MultiBlock job을 수행하면서 setRamBlockStatus가 True인 Block들에 대해서만 Ram에서 Dflash로 쓰기를 시도하기는 하지만 Index가 큰 쪽에서 작은 쪽으로 순차적으로 저장한다.
가령 특정 제어기의 경우에는 Fast IG 상황을 요구받을 때가 있다.
이럴 경우 NvM WriteAll에 주어지는 시간이 아주 제한적일 수 있다.
이때 Garbage Collection 상황이 걸리게 된다면, index가 낮은 블럭의 경우 저장이 보장받지 못할 수 있다.
따라서 NvM 블럭에 대한 정책을 구성할 때는 shutdown에 저장을 해야만 하는지를 고려해야 하고 run time에 저장이 가능하거나 1DC 중 한 번만 저장하면 되는 블럭의 경우에는 최대한 run time 저장에 배치하는 것도 고려해야 한다.
게다가 multiblock으로 저장되는 블럭의 job의 우선순위는 일반적으로 WriteBlock에 비해 낮다. (Microsar에서는 그렇다.)
'자동차 및 자동차 SW > AUTOSAR' 카테고리의 다른 글
DEM Overview (0) | 2023.08.03 |
---|---|
DTC logging 시에 AUTOSAR에서의 aging counter와 debounce counter의 역할은? (0) | 2023.07.31 |
FEE Module과 Garbage Collection (0) | 2023.07.31 |
NvM 개요 (0) | 2023.07.26 |
NvM은 내부적으로 어떤식으로 동작할까 (0) | 2023.07.25 |