마음 속 하늘은 항상 맑음~! Feel it, Learn it, Use it!

 램 컨트롤러의 문제로 크래시가 나타나는 줄 알았는데 그게 아니라 그래픽카드가 PCIE 최재 절전 상태에서 깨어나는 문제였다. 결론적으로 램 컨트롤러나 램의 문제는 없었다.

 Power Saving 전원설정을 찾아서 사용 중인데 거기 설정 중에는 PCIE 절전을 최대 절전으로 하는 부분이 있었는데 그 설정이 전력소비를 크게 줄여주지도 않으면서 문제를 일으킨 것 같다.

 PCIE 버스의 전력 설정을 건드리지 않고 그냥 그래픽카드의 자체 절전 기능을 믿는 것이 더 나은 것 같다.

 예전의 전압이나 다른 설정들로 트윅을 하던 잘못된 가설들은 크게 의미가 없어졌다.

 p.s.

  문제의 원인은 결국 글카였다. 메모리는 문제가 없었다. 참 엉뚱한 결론.

 비교적 적은 부품으로 전류 드라이버를 만들 수 있는 PT4115로 회로를 구성해봤는데 생각했던 것과는 달랐다.

 회로 구성이 전류를 조정하는 저항이 좀 낮은게 단점이지만 부품 개수가 칩을 포함해서 5개만 있으면 가능한 간단한 구성이라서 나름 효율적인데, 문제는 6V이상에서만 제대로 구동이 된다.

 보다 낮은 전압이나 미약한 전류에도 작동하도록 하려면 OP-AMP와 전류 측정저항을 이용하는 방법이 더 나은 것 같다.

 데이터시트를 보면 0.1/R 로 전류량을 제한하는데 300mA의 정전류로 만들려면 0.33 저항을 사용하면 된다. 만능기판에 구성한 회로에서는 최대 315mA까지 나오는 것 같다.

 0.1/R은 최대 전류치이고 DIM 핀을 통해서 PWM이나 최대 2.5V를 인가하는 것으로 전류를 조정하는 것도 가능하다.

 칩이 너무 적어서 SOP-8 to DIP 기판에 겨우 맞춰진다. 1.2A까지의 스펙이지만 발열 때문에 600mA는 변환기판에서는 사용하는게 힘들 듯.

 오래전에 아두이노에 10밀리옴 INA226 직류 전류 센서로 전류 장치를 만들다가 잠시 보류했다가 다시 만졌다.

 그런데 테스트 중에 직류 전류값이 너무 크게 나와서 보니, 보정값을 대충 저항값으로 연산해서 설정하는데 그 값이 순수 저항값에 센서 기판이나 납땜등에 의한 이유로 약간 큰 차이가 있었던 듯.

 결국 10밀리옴이었던 션트 저항치를  26밀리옴으로 조정하니 테스터에서 잰 값과 비슷한 적정값이 나왔다.

 센서에는 전압과 전력값이 있는데 무슨 이유인지 정확히 나오지 않는다.

 그리고 밀리값으로 읽는 정수형은 제대로 극성에 따라 +와 -값이 나오는데 실수형은 연산쪽에 문제가 있는지 극성과 상관없이 항상 -값이 자주 찍힌다. 아마 라이브러리 자체의 버그인 듯.

 여튼 가장 중요한건 10밀리옴의 션트이지만 추가적인 16밀리옴의 저항값이 전류값을 더 많이 나오게 하는 문제를 잡았다. 좀 더 큰 션트 저항이 달린 비슷한 모델의 직류 전류 센서에서도 아마 같은 문제가 있을 듯.

 전압 센싱은 잘 안되는 것 같고, 전류만 최대값이 1초 단위로 추가적으로 업데이트 되도록 수정.

 p.s.

  다시 26으로 cal 저항값을 조정. average 샘플 수와는 큰 차이가 없는 것 같다.

 혼용해서 메모리를 쓰는 경우에는 젠2는 좀 더 엄격한 구성을 필요로 하는 것 같다.

 젠+의 경우에는 CPU에 가까운 메모리 슬롯에 타이밍이 느린 램(SPD 정보에서 ns 타이밍이 높은 램)을 꽂고

 젠2의 경우에는 CPU에 가까운 메모리 슬롯에 타이밍이 빠른 램(SPD 정보에서 ns 타이밍이 낮은 램)을 꽂는게 더 안정적인 것 같다.

 메모리 컨트롤러의 미세한 차이가 있는 듯.

 Micron 모듈의 램이 다 그런건 아니겠지만 조금 오래된 램들(2017년 이전)은 tRDDS 값을 +1 해주는 것이 tRC나 tRAS를 +1 해주는 것보다 나은 것 같다. RDDS는 뱅크 사이의 RAS 딜레이 값인데 같은 뱅크의 RAS 딜레이 값인 tRDDL과는 비슷한 기능의 다른 값이다. tRDDS를 설정할 때 주의점은 tRDDS * 4의 값이 tFAW에서 2를 뺀 값과 비슷해야 한다(+2로 여유분을 두는 듯). tRDDS * 4 값이 tFAW 값보다 크면 안된다.

 03/17

 tRDDS로도 12일 정도가 지나자 레어 오류가 나와서 tFAW를 +1하고 테스트. 램컨 특성이라는게 참.

 tFAW는 전체 뱅크를 한번 돈다는 느낌으로 tRDDS * 4이지만 안정화에 tRDDS * 5나 tRDDS * 8로 설정하곤 함.

 03/23

 Zen2 메모리 안정화에는 tFAW 조정만큼 좋은게 없는 것 같다. 특히 XMP프로파일이 아니더래도 XMP의 클럭을 사용하는 경우에는 tFAW는 tRDDS * 5.5 5.6 ~ tRDDS * 6 혹은 tFAW(min) + tRDDS + 2 으로 해주면 훨씬 안정적인 상태가 되는 것 같다.

 03/28

 tFAW+1를 늘리는 것은 LiveKernelEvent 144(대부분은 그래픽카드 오류)를 제거하는데 효과적. wakeup이후에 여전히 발생하긴 하는데 그 오류가 딱 한번만 발생하고 안정화된다. tFAW+2를 하면 wakeup 이후에도 거의 발생하지 않는 것 같다.

 p.s.

 그냥 XMP램을 쓰면 SoC의 전압을 +0.02정도로 조금만 올려주는게 더 안정적인 듯. 다른 메모리 타이밍 문제가 아니었던 것 같다(수율 뽑기가 실패했다는 말도 된다).

 단, 타 메인보드 회사보다 인가 전압이 높다는 이야기가 있는 기가바이트 메인보드에서는 SoC전압값 올리는건 신중해야한다.

 아직 B350의 메인보드를 사용하고 있는데 마지막 바이오스는 베타인 관계로 여러가지 미흡한 점이 많다.

 그 중에 하나 문제인게 바로 팬 컨트롤. 이게 PWM제어가 너무 등락이 많이 생겨서 가볍게 사용하는 중에도 위잉위잉하는 소리가 끊이지 않는다.

 이 상태를 쭈욱 사용하다가 결국엔 해결을 보자면 건드렸는데, 하드웨어 모니터링의 온도와 PWM의 값이 너무 부절적한 값으로 만들어져 있었다.

 기본 쿨러의 값으로 셋팅한 것도 아니고 어느 쿨러에 맞추어서 셋팅했는지 모르겠다. 아니면 PWM 신호가 문제가 생겨서 쿨러가 빨리 돌아가는 것 같은데 제대로 알아낼 방법은 없었다.

 어쨌던 문제를 해결하는데 가장 좋은 온도는 45도이고, 쿨러팬에 따라 다르겠지만 PWM은 30%가 적당한 것 같다.

 이 값은 하드웨어 모니터링 툴로 대충 짐작해서 찍은건데, 45도 설정은 아마도 다른 쿨러에서도 고정으로 사용하는 기준으로 만들면 편하리라 본다. PWM값은 쿨링팬에 따라 다를텐데 30%면 가장 적정한 값이 아닌가 생각된다.

 여튼 이렇게 설정을 하고나서는 가벼운 작업에서는 급발진 쿨링팬 소음이 없이 정말 조용해졌다.

p.s.

 아무래도 메인보드의 PWM 컨트롤러가 고장난 것 같다. 문제해결은 간단하게 Auto를 DC mode로 수정하니 해결. PWM 컨트롤러가 고장나다니 슬프네.

 간단히 외부 센서를 통해 논리 ON/OFF를 하는 것으로, 2번핀은 외부신호 입력이고 3번핀은 출력, 그리고 7번핀은 초기화 대기 중에는 1, 초기화 후에는 0을 출력한다. 7번핀은 크게 의미가 없다. 인터럽트로 핀 입력을 감지하고 다음 입력과의 시간차를 32ms초 정도로 두어서 순식간에 점멸하는 신호에 반응하지 않도록 보완했다. 와치독 타이머를 두고 비정상 동작엔 다시 리셋하도록 되어있다.

program _12F675_touch;

{ Declarations section }
procedure Interrupt(); iv 0x0004; ics ICS_AUTO;
begin
  if T0IF_bit=1 then begin
    if GPIF_bit=1 then begin
      if GP5_bit=1 then begin
        GP4_bit:=not GP4_bit;
      end;
      GPIF_bit:=0;
    end;
    { reset timer0, 1000000 / 256 / 128 = 32ms }
    TMR0:=0;
    T0IF_bit:=0;
  end;
end;

begin
  CMCON:=7;
  ANSEL:=0;
  { signal IO }
  TRISIO4_bit:=0;
  GP4_bit:=0;
  { port change input }
  TRISIO5_bit:=1;
  { Interrupt }
  IOC5_bit:=1;
  GPIE_bit:=1;
  GIE_bit:=1;
  { timer1 }
  TMR1CS_bit:=0;
  T1CKPS1_bit:=1;
  T1CKPS0_bit:=0;
  TMR1ON_bit:=1;
  { timer 0 }
  PSA_bit:=1;
  PS2_bit:=1;
  PS1_bit:=1;
  PS0_bit:=1;
  T0CS_bit:=0;
  { }
  TRISIO0_bit:=0;
  GP0_bit:=1;
  Delay_100ms;
  GP0_bit:=0;
  
  
  while true do begin
    { reset watchdog }
    if T1IF_bit=1 then begin
      TMR1H:=0;
      TMR1L:=0;
      T1IF_bit:=0;
      ClrWDT;
    end;
  end;
end.

 텐다 공유기를 할인 가격에 가져왔지만, 잘 사용하다 펌웨어 업데이트를 잘못하는 바람에 망가졌다.

 완전히 망가진 것은 아니고, 더이상 펌웨어를 쓰기를 할수도 설정을 저장할 수도 없다.

 텐다 쪽에 문의를 했지만, 아직 답변을 받은 것이 없다.

 그냥 시장에 같은 물건이라도 다른 부품을 쓴 제품이 여럿 존재하는 것 같다.

 그래서 주의를 해야하는데 지역에 따라 다른 펌웨어를 쓰는데 그것도 유의해야 한다.

 덜컥 이게 굴러가겠지 하면서 굴리면 망가지는 경험을 하게될 수 있다.

 왜 이렇게 다른 부품의 존재는 그렇다치고 왜 펌웨어에 그 부품의 지원하는 기능을 빼버린 것인지.

LAN WAN isolate config...
Lan pbmp:0x000000ef
Wan pbmp:0x000000f0
use Switch new descriptor
<RealTek>FLI
JEDEC id 684015, EXT id 0x6840
found BH25D16

>>>>>No Flash Vendor support (0x00684015)<<<<<

use MXIC as flash vendor instead
BH25D16, size=2MB, erasesize=4KB, max_speed_hz=55000000Hz
auto_mode=0 addr_width=3 erase_opcode=0x00000020

 결국 뜯어서 직렬통신을 연결하고 로그 메시지엔 이런 내용이 있다.

 직렬통신의 속도는 38400으로만 맞추니 아주 잘 보인다.

 메시지는 지원하지 않는 플래시 메모리 회사 제품이고 MXIC로 인지해서 쓰겠단 메시지.

 그런 이유인지 플래시 쓰기가 불가능해졌다.

 결국 이 플래시 메모리를 교체해야할 것 같다.

 그리고 재난 모드로 들어가서 tftp를 활성화하는데 이 상태로 들어가는건 리셋 버튼을 15초 정도 누르고 있어야 한다.

 플래시 교체가 성공적인 작업이 된다는 보장도 없고, 어떻게 될지 모르겠다.

 절대로 텐다 제품은 펌웨어를 지역에 맞지 않는 것은 절대로 업데이트 하지 말아야 한다는 교훈을 얻었다.

 p.s. 러시아 쪽 포럼의 이야기를 보니 펌웨어 실수였던 듯. BH25D16은 MXIC 호환품인 것 같다.

 오랜동안 메모리 안정성에 대한 작업이 이루어졌지만 모든 메모리가 잘 맞는 것은 아니다.

 그래서 타이밍 외의 다른 메모리 컨트롤러의 값을 조정하여 안정화시키는 방법에 대한 내용을 보고 대충 이해한 부분만 대충 써본다.

 1. 메모리 타이밍의 경우에는 Tras 값을 늘리면 1차적인 타이밍 안정화가 이루어진다.

 2. 미세한 안정화를 위해 RTT PARK 값을 조정한다. 이는 시계의 분침 같은 것으로 ProcODT보다 세밀한 조정값이나 대부분 40~48만 사용한다. 더 높은 클럭의 경우에는 80까지 가는데 3200의 경우에는 48값을 넘을 일이 거의 없다.

 3. 그래도 안정화가 어렵다면 ProcODT값을 조정한다. 60이 한계값이나 더 높일수도 있다. 대부분 53.3이 기본값이다. ProcODT는 시계의 시침 같은 것으로 RTT PARK값보다 더 큰 값으로 단계를 조정한다. 40~60이 기본값이다.

 4. CAD 값은 초침 같은 것인데 값을 조정할 일이 없을 것이라 본다.

 미세한 안정성에는 RTT PARK 값을 조정하고 부팅시 메모리 호환성과 안정성에는 ProcODT를 사용하면 좋다고 본다.

 RTT PARK나 ProcODT 모두 높은 값일수록 안정성을 향상시키지만 항상 그 한계치가 있다는 것도 명심해야 한다.

 아주 가끔 윈도우즈의 일부 기능들이 알 수 없는 이유로 망가지는 현상에 대한 해결 방법을 찾았다.

 갑자기 검색 기능이 망가지는 바람에 시작된 삽질이지만 윈도우즈를 초기화 하거나 다시 설치하는 방법을 피할 수 있다.

 윈도우즈의 기본 패키지들의 설정들은 "사용자\AppData\Local\Packages 폴더 안에 모두 들어있다.

 그중에 윈도우즈의 패키지들은 "Microsoft.Windows." 라는 접두를 가지고 있고, 검색 기능의 경우에는 "Microsoft.Windows.Search_cw5n1h2txyewy"라는 이름을 가지고 있다.

 일단 이 폴더를 지워버리거나 이름을 바꿔야 하는데, 윈도우즈 계정을 사용하는 중에는 지우거나 이름을 바꾸는 것은 불가능하다. 그래서 다음과 같은 과정을 따른다.

 1. 새로운 로컬 관리자 계정을 만든다. 마이크로소프트 온라인 계정이 필요가 없다. 아니면 리눅스 복구 CD나 WinPE 같은 것으로 해당 폴더를 지운다. 새로운 또다른 로컬 관리자 계정으로 작업을 하면 부팅이 없이도 로그인/로그아웃으로도 가능하다.

 2. 새로운 만든 관리자 계정으로 로그인하거나 리눅스 복구 CD 혹은 WinPE로 해당 폴더를 지우거나 이름을 바꾼다.

 3. 그리고 새로운 만든 계정에서 로그아웃을 하거나 재부팅을 한다.

 4. 이제 다시 윈도우즈 패키지를 설치해야 하는데, 컨트롤 X를 눌러서 Power Shell을 선택하고 다음과 같은 명령을 실행해야 한다.

Add-AppxPackage -Path “C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\Appxmanifest.xml” -DisableDevelopmentMode -Register

5. 그러면 다시 검색 기능이 되돌아온다.

 만약 다른 윈도우즈 패키지 기능이 고장난 상태라면 "Microsoft.Windows.Search_cw5n1h2txyewy" 부분을 해당 폴더이름으로 대체하면 그 윈도우즈 패키지를 다시 설치할 수 있다.

 아두이노 프로 마이크로가 USB장치 만느는데 아주 좋다는 이야길 듣고, 아주 예전에 있었던 아날로그 조이패드를 개조했다. 그냥 연결하는데는 방향 컨트롤이 문제가 있어서 방향키 부분을 잘라내고, 그곳에 KY-023 2축 조이스틱 모듈을 붙이고 스위치 1개를 더 얻었다. 사실 다른 옵션이 없어서 그냥 선택한 부품.

 아두이노의 조이스틱 라이브러리를 사용해서 코드를 구성했다.

 노이즈 같은 중간값에 흔들림이 조금 있어서 흔들림을 무시하도록 조정하기도 했다(NOISE_X, NOISE_Y).

 XCV와 YCV는 중심값으로 127근처로 나온다. USB포트의 약간의 전압드랍으로 125가 나온 듯.

 3.3V로 나중엔 변경해야겠다.

 A0와 A1이 각각 X,Y축이고 버튼들은 0V에 눌러진 상태가 된다.

 버튼에 대한 핀번호를 따로 할당할 수 있게 코드를 수정했다.

#include <Joystick.h>
#include <wiring_private.h>


#define MAX_BUTTON 7
//#define DEBUG_XY
#define FASTADC

#define XCV 125
#define YCV 125
#define NOISE_X 4
#define NOISE_Y 4

Joystick_ Joystick(JOYSTICK_DEFAULT_REPORT_ID, JOYSTICK_TYPE_JOYSTICK /* JOYSTICK_TYPE_GAMEPAD */,
                   MAX_BUTTON, 0,
                   true, true, false,  // x, y, z axis
                   false, false, false,
                   false, false,
                   false, false, false);

int jbutton[MAX_BUTTON]={5,6,7,8,9,14,16};
int xbv, ybv;
unsigned long sp,ep;

void setup() {
  for (int index = 0; index < MAX_BUTTON; index++) {
    pinMode(jbutton[index], INPUT_PULLUP);    
  }

#ifdef FASTADC
 // set prescale to 16
 sbi(ADCSRA,ADPS2);
 cbi(ADCSRA,ADPS1);
 cbi(ADCSRA,ADPS0);
#endif

  xbv=analogRead(A0) >> 2;  // 127
  ybv=analogRead(A1) >> 2;  // 127
  
  Joystick.begin(); 
  Joystick.setXAxisRange(-127,127);
  Joystick.setYAxisRange(-127,127);
  #ifdef DEBUG_XY
  sp=millis();
  #endif
}

int lastButtonState[MAX_BUTTON] = {0,0,0,0,0,0,0};
int xv, yv;

void loop() {
  xv=(analogRead(A0)>>2);
  xv+=(analogRead(A0)>>2);
  xv>>=1;
  xv-=XCV;
  if(xv<-127) xv=-127;
    else if(xv>127) xv=127;
  if(xv<NOISE_X && xv > -NOISE_X) xv=0;
  
  yv=(analogRead(A1)>>2);
  yv+=(analogRead(A1)>>2);
  yv>>=1;
  yv-=YCV;
  if(yv<-127) yv=-127;
    else if(yv>127) yv=127;
  if(yv<NOISE_Y && yv > -NOISE_Y) yv=0;

  #ifdef DEBUG_XY
  ep=millis();
  if(ep-sp>100) {
    Serial.println(xv);
    Serial.println(yv);
    Serial.println(xbv);
    Serial.println(ybv);
    Serial.println("===");
    sp=ep;
  }
  #endif
    
  Joystick.setXAxis(xv);
  Joystick.setYAxis(yv);

  // Read pin values
  for (int index = 0; index < MAX_BUTTON; index++)
  {
    int currentButtonState = !digitalRead(jbutton[index]);
    if (currentButtonState != lastButtonState[index])
    {
      Joystick.setButton(index, currentButtonState);
      lastButtonState[index] = currentButtonState;
    }
  }
}