질문을 이해하지 못했습니다.
소스 코드는 여기에 있습니다
여전히 네가 무엇을 묻고 싶은지 이해가 안 가
블로거님, 도와주셔서 감사합니다. 보조 전원 모듈만 수정했는데 DCDC 강압 모듈을 NDP2355KC 모듈로 변경했고, 파워 인덕터는 PSPMAA0605H-100M-ANP를 사용했습니다. 문제는 16V 등의 입력 전압일 때 10V 정도의 출력 전압을 설정하려고 하면, C 포트에서 전원을 공급받을 경우 시스템이 재시작되거나, 안정화된 전원 공급 시 과전류가 발생해 최대 전류가 직접 출력됩니다. 직류 전원 공급 시 전원 단이 CC 모드로 들어가 출력 전압이 약 6V 정도 되고, 보드의 MOSFET이 매우 뜨거워집니다. 이 현상을 분석해 주실 수 있나요? 감사합니다.
출력 단자에 단락이 없는지 확인해 보세요
PCB 레이아웃을 확인해 보세요
출력도 단락이 없습니다
그 저항이 실수로 돌려졌습니다. PCB에는 문제가 없고, 전류 측정에서 켈빈 선로를 사용해야 한다는 점은 제가 действительно 주의하지 못했습니다. 블로그 주인님의 알려주심에 감사합니다.
이 HRTIM에서 PWM 주기의 중심점에 ADC 샘플링을 트리거하려면 어떻게 설정하나요? 설정을 해봤는데 트리거 타이밍이 좀 이상하네요. 제가 설정한 것보다 훨씬 늦게 발생합니다. 문제가 어디에 있는지 어떻게 확인해야 할까요?
어떻게 설정했는지 스크린샷 찍어서 보여줘
테스트해보니 제 PC15 핀의 반전 시점이 설정한 시점보다 항상 2.5uS 늦습니다. 다음은 제 테스트 함수입니다.
// 콜백 함수
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc)
{
// ADC1_2_IRQHandler();
if (hadc->Instance == ADC2)
{
GPIOC->ODR ^= GPIO_PIN_15;
Control_Loop_Update(); // 고주파 제어 루프
// GPIOC->ODR ^= GPIO_PIN_15;
}
else if (hadc->Instance == ADC1)
{
// GPIOC->ODR ^= GPIO_PIN_13;
// flag_adc1 = 1;
PID_V();
GPIOC->ODR ^= GPIO_PIN_13;
}
// HAL_GPIO_WritePin(GPIOB, GPIO_PIN_15, GPIO_PIN_RESET); // Low로 설정
}
이 스크린샷은 왜 순서가 섞였는지 모르겠어 ![]()
형, 이 테스트 방법 자체가 문제가 있네. 네가 HAL_ADC_ConvCpltCallback 안에서 IO를 토글해서 잰 건 ‘트리거 시간’이 아니라 ‘ADC 샘플링 시간 + 변환 시간 + 인터럽트 응답 지연 + HAL 라이브러리의 거대한 조건 판별 오버헤드’야.
HAL_ADC_IRQHandler 안으로 들어가서 소스 코드를 직접 확인해 봐. ST의 HAL 라이브러리는 이 콜백을 부르기 전에 레지스터 상태를 한가득 체크하거든. 그 사이에 1~2µs가 훌쩍 날아가는 건 너무나도 당연한 일이지. 게다가 네 스크린샷에 설정된 샘플링 시간이 6.5사이클이고 변환에도 12.5사이클이 필요하잖아. 이건 다 실제로 꼬박 소모되는 시간이라고.
진짜 트리거 지점을 측정하고 싶다면, 타이머 출력 비교 핀을 직접 설정해서 오실로스코프로 PWM 파형과 그 출력 핀을 같이 찍어봐. 꼭 인터럽트 안에서 측정해야겠다면, HAL 라이브러리는 버리고 스타트업 파일에서 ADC 인터럽트 엔트리를 직접 찾아가서 진입하자마자 첫 줄에서 GPIO를 토글해 봐. 지연이 순식간에 확 줄어드는 걸 볼 수 있을 거야.
CubeMX 스크린샷을 확인해 봤는데, 몇 가지 의심되는 부분을 확인해 보세요:
- ADC 트리거 소스가
Timer C Compare 3로 설정되어 있는데, Timer C 설정에서 Compare 3을46080 / 4로 설정하신 것 같네요. PWM 주기가 46080이라면 중심점은/2여야 하지 않나요? (중앙 정렬 모드를 사용 중이시라면 따로 계산해 봐야겠지만요). - ADC 트리거 엣지를
Trigger detection on the falling edge(하강 엣지 트리거)로 선택하셨는데, HRTIM이 생성하는 트리거 이벤트가 예상하신 시점에 하강 엣지인지 확인하셨나요? 보통은 기본적으로 상승 엣지로 설정하는 경우가 더 많습니다. - 윗분께서 말씀하신 것처럼 2.5uS는 확실히 소프트웨어 오버헤드입니다. G474 메인 클럭이 170MHz라면 2.5uS면 400개가 넘는 명령어를 실행할 수 있는데, 이게 전부 인터럽트 진입 시 스택 푸시와 HAL 라이브러리의 if 조건문에 낭비되고 있는 겁니다. DMA를 활용하시는 걸 권장합니다. ADC 샘플링이 끝나면 바로 DMA 전송을 트리거하게 두고, CPU 인터럽트로 기다리지 마세요.
맞아요, 이후에 다시 테스트해 보니 ADC1_2_IRQHandler 함수에 넣으니 지연이 거의 없어졌습니다.
고수님들, 지금 테스트를 진행 중인데요, 처음에는 정상 작동했습니다(출력 '리플’이 제 스위칭 주파수와 같은데 진폭이 커졌고, 주파수도 아주 높았습니다. 아래 사진 참조). 그 후 출력 커패시터를 몇 개 추가하고 다시 전원을 인가했더니, 32의 ADC가 전부 고장난 것 같습니다. 지금은 ADC 핀에서 읽히는 값이 외부 입력이 얼마든 다 똑같아요. 이게 무슨 원인 때문일까요? 제 입력 전압은 40V이고 출력은 30V로 설정했으며, 부하는 20R입니다. 한 가지 여쭤보고 싶은데, 테스트 모듈 뒤에 32 핀을 보호하는 부품을 추가해야 하나요? 추가해야 한다면 추천하는 부품이 있을까요? 고수님들 감사합니다!
무슨 말을 하는지 모르겠는데, 이게 내가 오픈소스로 공개한 보드야?
토폴로지는 같고, 그냥 제가 직접 그린 거예요
제 질문은요,
-
출력 AC 성분을 측정한 그래프에서 왜 이렇게 높은 스파이크가 나타나나요? 스위칭 주기 1개당 4번씩 나타나는데, 이 영향을 어떻게 없앨 수 있을까요?
-
보드 테스트 중에 STM32의 ADC 부분이 전부 망가졌어요. 왜 ADC 부분이 손상되었는지 모르겠어요. ADC 핀 앞에 RC 로우패스 필터도 넣었는데 결국 ADC 핀이 망가졌어요. 이게 무슨 원인 때문일까요? 이전 질문에서는 ADC 핀 손상을 의심했는데, 지금은 진짜 망가진 게 확실해졌어요. (위 그래프의 AC 성분 스파이크가 너무 높아서 STM32 ADC 핀이 손상된 것 같은데, 제 추측이 맞는지 모르겠어요.) 이미 메인 컨트롤러 2개를 망가뜨렸고, 다 ADC 핀 손상 때문인데 원인을 찾을 수가 없어요.
-
STM32의 ADC 핀에 추가 보호를 해서 ADC 입력을 0~3.3V 사이로 제한하고 싶은데, 좋은 방법이나 부품이 있을까요?














