COSMOSRKSI
방명록 RSS 태그 글쓰기 관리자
 
Windows Phone Link 연결 문제 해결 방법: 재설치 방법 관점에서
真有益 2026-10-22 19:02:35

Windows Phone Link 연결에 문제가 발생하여 안드로이드의 Link to Windows 캐시 삭제, 윈도우에서 repair 및 reset을 하였으나 해결되지 않음.

 

아래와 같이 재설치를 진행하여 연결 문제를 해결함.

 

power shell에서

 

1) phone link를 삭제하기 위해 아래 명령어를 입력

Get-AppxPackage Microsoft.YourPhone -AllUsers | Remove-AppxPackage

 

2) 재부팅 후 아래 명령어를 입력하여 Phone Link를 설치

winget install 9NMPJ99VJBWV

 

3) 다시 재부팅 후 Phone Link를 실행

 

도움이 되길 바라며.



stm32에서 printf 쉽게 사용하는 방법
카테고리 없음 2026-08-23 14:24:14

마이크로 컨트롤러에서 printf는 변수 상태 확인, 디버깅, 센서값 출력 등 많은 용도로 사용됨.

 

이를 쉽게 사용하기 위한 설정 방법은 아래와 같음.

 

/* USER CODE BEGIN 4 */
int __io_putchar(int ch) {
    HAL_UART_Transmit(&huart1, (uint8_t*)&ch, 1, HAL_MAX_DELAY);
    return ch;
}
/* USER CODE END 4 */

 

uart 핸들러 번호는 사용 환경에 맞춰 설정할 것.



CoolTerm을 이용한 UART 데이터 수신 시 데이터 깨짐 문제 해결 방법.

CoolTerm을 이용하여 STM32에 인터페이스된 IMU의 6축 데이터를 PC에서 수신하는 코드를 작성함.

 

하지만 데이터 수신 시 데이터 깨짐 문제를 확인함.

 

이를 해결하기 위해 아래의 절차를 수행함.

 

1) Option -> Receive 탭에서 Wait for line ending을 체크

 

2) STM32 코드상에서 출력문의 마지막에 carriage return, line feed 옵션 넣기

 

 

위 해결 방법을 따를 시 아래와 같이 문제가 해결됨을 알 수 있음.

 

누군가에게 도움이 되길 바라며.



STM32 Cortex 시스템의 메모리 접근 위반 및 HardFault 메커니즘 분석

STM32 마이크로컨트롤러 환경에서 발생할 수 있는 무단 메모리 접근 및 정의되지 않은 영역 침범 시 발생하는 하드웨어 Fault 메커니즘과 이로 인해 HardFault가 유발되는 물리적 과정을 분석한다.

 

1. 개요

ARM Cortex-M 코어 아키텍처는 시스템 안정성과 무결성을 실시간으로 모니터링하기 위해 하드웨어 기반의 Fault 감지 로직(Fault Detection Logic)을 내장하고 있다. 개발 과정에서 하드웨어 초기화 이전에 특정 메모리 주소를 참조하거나 스택 오버플로우 등의 결함이 발생할 경우, 코어는 이를 감지하여 예외를 발생시킨다.

 

2. 하드웨어 예외 감시 장치 아키텍처

Cortext-M 코어 내부에는 예외의 성격과 발생 원인에 따라 세분화된 3개의 하드웨어 fault 감지 모듈이 존재한다.

 

2.1 예외 종류 및 하드웨어적 원인

예외 유형 감시 대상 및 하드웨어적 유발원인 예시
BusFault 버스 매트릭스상에서 존재하지 않는 주소 버스를 디코딩하거나, 응답이 없는 외부 슬레이브 장치에 데이터를 요청할 때 타임아웃 발생 FMC 초기화 시퀀스 완료전 LCD 컨트럴러가 버스를 통해 해당 메모리 주소를 강제 참조할 때
UsageFault 정의되지 않은 명령어를 디코드하거나, 실행 불가능한 주소로 분기 또는 0으로 나누기 연산 수행 시 감지 스택 오버플로우로 인해 함수 리턴 주소가 오염되어 비정상적인 메모리 번지로 코어가 점프할 때 발생
MemManageFault 내부 MPU(Memory Projection Unit)가 정의한 메모리 맵의 속성(Read only 등)을 위반하여 데이터를 쓰거나, 실행 권한이 없는 영역에서 코드를 Fetch할 때 차단 데이터 영역으로 할당된 플래시 메모리 또는 특정 특수 목적 레지스터 영억에 비정상적인 포인터 연산으로 접근 시 발생

 

3. HardFault Escalation 메커니즘

많은 임베디드 환경에서 위 3가지 개별 fault 상황이 발생했음에도 불구하고 최종적으로 항상 HardFault_Handler로 진입하게 된다. 이는 ARM 코어의 Fault Escalation 시스템 때문이다.

 

3.1 SHCSR(시스템 핸들러 및 제어 및 상태 레지스터)의 역할

칩이 부팅된 직후(reset 상태), SCB(시스템 제어 블록)의 SHCSR(System Handler control and Status Register) 내부의 BUSFAULTENA, USGFAULTENA, MEMFAULTENA 비트는 모두 0 (Disabled)으로 설정되어 있다.

 

개별 핸들러가 비활성화된 상태에서 감시 조건이 감지되면, 코어는 하드웨어 수준에서 해당 오류를 최상위 치명적 결함으로 판단하여 즉시 HardFault 등급으로 격상한다. 즉, HardFault는 개별 비상벨이 꺼져 있을 때 동작하는 시스템 전체의 최종 종합 비상 셧다운 루틴이다.

 

4. 하드웨어 감시 장치의 당위성

만약 아키텍처 내에 이러한 메모리 침범 감시 로직이 존재하지 않는다면, 코어는 잘못된 주소에서 읽어 들인 쓰레기값을 정상 명령으로 인하여 무작위 연상을 지속하게 된다. 

이는 전역 변수 영역 오염, 데이터 버스 충돌을 유발하고 외부 액추에이터 및 하드웨어의 오동작으로 이어질 수 있다.

따라서, HardFault를 통한 시스템 정지는 물리적 피해를 막고 시스템을 안전한 상태로 유지하기 위한 필수적인 안전장치이다.

 




이 사이트에는
넥슨코리아에서 제공한 넥슨 Lv.1 고딕 Regular체,
카페24가 제작한 아네모네체,
Cadson Demak가 디자인한 Kanit체,
Sandoll이 디자인한 나눔고딕체가
적용되어 있습니다.
멋진 폰트를 무료로 제공해주셔서 감사합니다.

Copyleft ⓒ bskyvision (블루스킨 v1.2)