AUTOSAR OS Task를 자주 확인하자

AUTOSAR Bring up 작업을 하다보니, 옛날에 마주했던 이슈들이나 혹은 tool 버전이 변경되서 마주하는 문제들이 매 순간 순간 나타나고 있다. 

 

오늘 이야기할 주제는 OS Task Mapping에 대한 이야기이다.

AUTOSAR에서는 application software의 경우, runnable이라는 단위로 각 기능 동작을 수행하고, BSW는 주로 mainfunction이라는 이름으로 기능 동작을 수행한다.

보통 AUTOSAR Project를 Set up하다보면 기본적으로 BSW configuration을 마친 상태에서 각 Core 별 Timer 설정, OS Application 생성, 각 주기 별 Task 생성과 각 Runnable 및 Mainfunction의 Task Mapping을 하게된다.

오늘 겪었던 이슈는 Application SW에서 userRequest API로 Full Communication 명령을 내보냈음에도, CanSM의 Bus State가 No Com에서 변하지 않았던 이슈이다.

보통 AUTOSAR 구현체 제공업체의 코드를 살펴보면, 각 사별로 나름의 규칙에 맞게 코드를 작성해놓았다. 그 중에서 Vector 사의 경우, 코드 해독 어려움으로 업계에서 악명이 높은데, 정말 왜 필요한 지 모를 매크로와 함수 포인터의 무분벼한 사용으로 이슈 발생 시 디버깅이 참 어렵다.

오늘 이슈의 경우에도 우선 문제 발생 후, 원인은 ComM request가 분명 CanSM으로 가지 않았을 것이다. 에서 시작했으나, 주구창장 구현체 코드만 뜯어보고 디버깅하고 있었다. 

결국 원인을 찾았으니, 바로 ComM_Mainfunction이 정상적으로 호출되고 있지 않았던 것이다. userRequest API야 Application sw에서 호출했고, 이를 통해 특정 CAN ch을 통신 하라는 명령은 가지고 있었을 것이다.

다만 해당 Mode로 천이하기 위해서는 ComM이 CanSM에게 해당 정보를 줬어야 했는데, 그게 못가고 있던 것이다.

그래서 OS 쪽 설정들을 살펴보니, 같은 10ms Task에 Mapping되어 있었음에도, ComM의 경우에는 특정 event로 감싸져 있었다. 내가 의도한건 전부 알람으로 동작하는 Basic Task였는데, 실상은 Extended Task형태로 구현되어 있던 것이다.

그래서 얻은 교훈은 뭔가 의도대로 동작하지 않을 때는 우선 Task를 보라!