십자성군의 비밀의 방

28377 D와 S의 SRAM 차이는

Dedicated and Local Shared RAM 에서 36Kbyte 차이나고

Message Ram에서 4Kbyte 차이납니다.

Dedicated and Local Shared RAM은 LS RAM과 GS RAM을 의미합니다(아마도 M0, M1까지 포함한다고 생각합니다.)

계산하면 (1+1+2*6+2*2)*16/8 = 36 입니다.

근데 이게 CPU 1개당 RAM이기 때문에 28377xD는 36Kbyte가 더 많습니다.

Message Ram은 28377xD 에서 CPU2 to CPU1 MSGRAM, CPU1 to CPU2 MSGRAM 을 나타냅니다 ( (1*16+1*16)/8 = 4)

DSP 디버깅에서 확인한 프로그램을 MCU에 업로드할 경우, 기본적으로 제공되는 예제와 같이 flash 영역에 기재할 경우 ROM 영역에서 돌아가는 프로그램은 전체적으로 속도가 느리다. 따라서 디버깅때와는 달리 프로그램이 제대로 돌아가지 않는 경우가 많다.

이를 해결하기 위해서 (1)중요한 변수나 함수영역의 일부를 ram 영역에서 구동하는 방법이 있지만, 코드의 규모이 비교적 소규모이고 전체적으로 디버깅때와 같은 처리속도가 필요하다면, 아예 (2)모든 code를 ram 영역으로 옮기는것도 한 방법이다.

(1)의 방법으로는 일일이 선언해줘야 하는 문제도 있기 때문에 본인으로써는 왠만하면 (2)의 방법을 추천한다.

또한 DSP28377의 경우 ram 영역의 크기가 28335의 3배에 가깝기 때문에 코드의 규모가 비교적 크더라도 적재할 수 있다.

이번 글에서 설명할 것은 코드의 규모가 큰 경우를 위한 메모리 배치와 flash programming이다.

아래는 메모리 배치의 cmd파일의 내용이다. 어느정도 cmd 파일을 건드려 보았다는 전제하에 자세한 설명은 생략한다. 또한 앞글의 reference를 반드시 먼저 확인하기 바란다.

1.

2.

3.

주의해야할 영역은 .stack영역이다. 이 영역은 RAMM0, RAMM1, RAMD0, RAMD1 영역등이 반드시 포함되어야 한다. 그렇지 않을 경우 프로그램을 실행하였을 때 에러관련 인터럽트가 걸려 에러함수에 진입한다.

그 외에 .cinit, .pinit, .econst, .switch 는 GSxRAM을 사용할 수 있다. .text또한 GSxRAM을 사용할 수 있다.

보통 프로젝트를 설계할 때 .text와 .stack 영역의 메모리가 부족한 경우가 종종 발생한다. .stack의 경우 변수 및 함수를 포함한 정적 메모리할당이 관련하며, .text는 프로그램 코드 자체의 크기에 관여한다. 즉, 프로젝트의 소스 규모가 크면 클수록 .text와 .stack이 요구하는 메모리가 커진다고 할 수 있다.

메모리 영역을 공유하여도 되지만 어차피 28377이 제공하는 RAM 영역이 꽤나 크기 때문에 공유하는 일 없이 배치해주었다.

4.

ramfuncs는 (1)방법에서 사용되는 영역이기 때문에 FLASH 영역만 배정하였다. 이 영역을 쓸 일은 없을것이다.

//--------------------------------------------

아래는 플래시 작업을 위해서 변경해야할 파일들이다.

DSP28xxx_SectionCopy_nonBIOS.asm

F2837xD_CodeStartBranch.asm

2837xD_FLASH.cmd

F2837xD_usDelay.asm

F2837xD_SysCtrl.c

DSP28xxx_SectionCopy_nonBIOS.asm 파일은 위에서 선언한 RAM영역에의 메모리 배치를 수행하는 어셈블리어가 짜여있다.

저 위의 파일들을 변경하는 것으로 28377의 디버깅모드로 사용하던 DSP를 동일한 성능으로 stand alone 모드로 사용할 수 있다. 변경전에 디버깅모드로 사용하던 당시의 파일들을 백업하는 것을 잊지말자.

※참고

flash 프로그래밍을 한 이후에 No source available for 어쩌구 하는 로그가 뜰 때가 있습니다.

이 때 디버깅의 진행버튼(> 버튼)을 눌렀을 때 진행이 된다면 아무런 문제가 없는 것입니다.

저의 경우 No source available for "0x3fe493" 라는 로그가 떴습니다.

0x3fe493 이라는 주소는 메모리맵을 참조했을 때 Boot ROM 영역에 있는 주소입니다.(Boot ROM은 0x3F8000~0x3FFFBF 영역을 차지합니다.)

이는 저희가 사용하는 ccs로는 boot rom 영역에 대한 디버깅을 할 수 없기 때문입니다. 이는 DSP의 부트롬 영역에 내장되어 있는 부분이니 저희가 건드릴 일은 없으니 걱정하지 않으셔도 됩니다.

단, 위 로그가 뜬 후에 진행버튼(> 버튼)을 눌렀는데도 프로그램이 진행되지 않는다면 cmd파일에서 메모리를 잘못 배치한 부분이 있을 수 있으니 원인을 알아보시기 바랍니다.

제가 고생한 만큼 이 글을 참고하시는 분들께 도움이 되기를 바랍니다

DSP 28335 관련

TMS320F28x CPU이해.ppt

tms320f28335.pdf

//-----------------------------------------------

DSP 28377 관련

Datasheet_F28377D-176_M_V100.pdf

Running an Application from Internal Flash Memory.pdf

Copying Compiler Sections From Flash to RAM.pdf

플래시 관련 자료를 압축해서 올립니다.

관련 문서.zip

아래는 결과적으로 RAM, FLASH 변경할 때 바뀌는 파일들입니다.(개인적으로 수정이 되어있습니다.)

flash.zip

ram.zip

참고로 이번 자료에서 사용하는 방법은 flash에 들어가야 하는 프로그램을 RAM에 모조리 load해서 프로세스를 빠르게 운행하는 것입니다. 이는 사용하는 DSP의 내부 RAM의 용량이 충분하거나 프로젝트가 소규모일 때 사용하는 방법입니다.

내부 RAM의 용량이 작거나 프로젝트의 규모가 클 때는 전체 프로그램이 아니라 일부 함수만 RAM에 올리는 방법을 사용한다고 합니다.

#define SYSCLK 150E6 /* 150MHz */

#define TBCLK 2343750 /* 60MHz */

#define     PWMCARRIER 20000 /* 20KHz */ (? : 목표 pwm 주파수?)

void InitEPwm1Module(void)

{

/* Setup TBCLK */

//PWM Counter Set

EPwm1Regs.TBPRD = (TBCLK/PWMCARRIER)-1;                         /* Set Timer Period */

EPwm1Regs.TBCTR = 0;                 /* Clear Counter */

/* Set Compare values */

EPwm1Regs.CMPA.half.CMPA = ((EPwm1Regs.TBPRD+1)>>1); /* Set Compare A value to 50% */

EPwm1Regs.CMPB = ((EPwm1Regs.TBPRD+1)>>1); /* Set Compare B value to 50% */

/* Setup counter mode */

EPwm1Regs.TBCTL.bit.CTRMODE = TB_COUNT_UP; /* Count Up (Asymmetric) */

EPwm1Regs.TBPHS.half.TBPHS = 0; /* Phase is 0 */

EPwm1Regs.TBCTL.bit.PHSEN = TB_DISABLE; /* Disable phase loading */

EPwm1Regs.TBCTL.bit.PRDLD = TB_SHADOW; /* Period Register is loaded from its shadow when                                                                                 CNTR=Zero */

EPwm1Regs.TBCTL.bit.HSPCLKDIV = 0x0;                 /* Clock ratio to SYSCLKOUT */

EPwm1Regs.TBCTL.bit.CLKDIV = 0x6;                 /* TBCLK = SYSCLK / (HSPCLKDIV * CLKDIV) */ //important

/* Setup shadowing */

EPwm1Regs.CMPCTL.bit.SHDWAMODE = CC_SHADOW; /* Enable Shadowing */

EPwm1Regs.CMPCTL.bit.LOADAMODE = CC_CTR_ZERO; /* Load on CNTR=Zero */

EPwm1Regs.CMPCTL.bit.SHDWBMODE = CC_SHADOW;

EPwm1Regs.CMPCTL.bit.LOADBMODE = CC_CTR_ZERO;

/* Set actions */

EPwm1Regs.AQCTLA.bit.ZRO = AQ_SET;                 /* Set EPWM1A on CNTR=Zero */

EPwm1Regs.AQCTLA.bit.CAU = AQ_CLEAR;                 /* Clear EPWM1A on event A, up count */

EPwm1Regs.AQCTLB.bit.ZRO = AQ_SET;

EPwm1Regs.AQCTLB.bit.CBU = AQ_CLEAR;

}

이전 자료와 함께 설명한다.(http://yeahhappyday.tistory.com/search/epwm)

DSP 28335의 SYSCLK는 150Mhz 이다.

TBCLK는 Time Base clock을 의미하며 pwm의 clock으로써 사용한다.

이는 SYSCLK에서 분배하여 그 값을 정하며 수식적으로는 위에 표시해 놓았듯이 TBCLK = SYSCLK / (HSPCLKDIV * CLKDIV) 이다.

관련 그림은 다음과 같다.

위 소스에서는 CLKDIV를 0x6, HSPCLKDIV를 0으로 해놓았기 때문에 TBCLK는 150Mhz/64 로 2343750hz 가 된다.

위 그림을 보면 어떻게 돌아가는지 일목요연하다.

코드에 설정해 놓은것을 분석해 놓으면

150Mhz인 SYSCLK에서 1/64를 한 값인 2343750hz를 TBCLK로 설정하였으며

이에 역수를 취한 2343750^(-1) 값은 4.26e-7인데 이는 PWM생성을 위한 카운트 주기가 된다.

TBPRD값을 2343750/20000-1을 한 값은 116인데 이는 위에 설정한 카운트 주기에 대하여 117회 카운트를 한 것을 PWM의 1주기로 잡는다는 것이다.

따라서 (4.26e-7)*117 = 0.00004992 로 약 0.05ms(20kHz) 를 pwm의 한 주기로 설정한다는 것이다.

TBCLK : 2343750hz : 4.26e-7 (sec)

TBPRD : 117 count

PWM 주기 : 4.26e-7 * 117 = 0.00004992 (sec)

DSP에 이것저것 코드를 넣다보면 헤더나 소스파일이 늘어나고 새로 만드는 함수도 많아진다. 그냥 쌩코딩을 할 경우는 그닥 마주칠 일이 없지만 기능별로 함수를 분류하다보면 빌드할 때는 아무런 에러도 없던것이 유독 실행만 하면 문제가 발생하는 경우가 있다.

예를 들어 평소에 문제 없이 돌아가던 코드에 함수 몇개 추가했더니

아래와 같은 ILLEGAL_ISR 인터럽트에 걸렸다. 

이녀석이 발생하는 경우는 하드웨어/소프트웨어 적으로 다양하다만 아래와 같이 추가했던 함수 몇개를 주석처리하면 평범하게 돌아갔다.

그럼 예상할 수 있는건 함수가 잘못되었던지 함수를 추가한게 문제인지 둘 중 하나일 것이다. 함수에 문제는 없었으므로 함수를 추가한게 문제겠고 그렇다면 메모리 문제일거라고 예상하였다.

메모리 문제라면 cmd파일 관련일 것이고 이에 대한 정보를 찾아보면

.stack이 함수 호출을 위한 메모리라는 것을 알 수 있다.

DSP 28377D를 사용했었는데 cmd파일의 메모리를 살펴보면 아래와 같다.

.stack에 'RAMM1 | 확장할 메모리 영역' 을 적용하고

프로젝트의 Properties->Build->C2000 Linker->Basic Options->Set C system stack size에 메모리 크기를 조정하면 해결된다.

단, 확장할 메모리가 PAGE1의 아무거나 선택하면 되는게 아니라 RAMD1과 같은 on-chip RAM이어야 효과가 있다.

http://www.mcublog.co.kr/279

일반 PC와 다르게 MCU는 메모리가 크게 제한되어 있다.

기본적으로 DSP 28335는 Stack과 Heap이 0x400으로 설정되어 있다.

기본적으로 작은 프로젝트에서는 크게 신경쓸것 없으나 규모가 커질수록 신경을 많이 써줘야 한다.

메모리 설정에 대한 문제 사례와 해결을 확인하자.

위 사진은 Stack과 Heap의 메모리를 설정하는 부분이다. 기본값으로 되어있다.

위 사진은 현재 다루고 있는 프로젝트에서 클래스 선언 관련 부분이다.

IMUTranslator, IMUSensor, GPSSensor, wSession, Actuator, sHeading 등등 다양한 클래스 변수들이 정적으로 선언되어 있다.

단순하게 new를 사용하지 않고 선언하였다.

이 때 발생하는 문제를 확인하자.

위 사진은 센서로부터 받은 데이터를 처리하고 전송하기 전의 함수이다.

약 300*2 byte 크기의 버퍼이며 주소는 0x00000630이다

호출된 함수에서 참조된 배열의 주소가 0x00000000 이 되어있다.

0이 아닌 다른 주소가 전달되기도 하고 dataLength값이 변하거나 해당 클래스의 다른 변수값들이 변동되기도 한다.

이런 현상은 정적으로 선언된 배열의 길이가 매우 길때도 종종 발생한다.

원인은 stack 메모리 부족인 것으로 확인되었다. 어떤 과정을 거쳐서 저 주소값이 전달된지는 필자도 잘 모르겠다.

----------------------

그럼 이제 해결법을 제시한다.

1. 동적 메모리 사용

위 사진같이 new 나 malloc을 사용한 동적할당을 이용한다. 이렇게 하면 Stack 대신 Heap 메모리를 사용하게 된다.

2. 정적 메모리 증가

위와 같이 정적 메모리를 늘리기 위한 두가지 과정을 거치면 된다.

cmd 파일의 .stack을 RAMM1 에서 RAMM1|RAML6 으로 변경하였다.

주소값이 정상적으로 전달되었음을 확인할 수 있다.

해결)

main문 안에서 선언한다

1)

SCIA_Class* CSCIA;

SCIB_Class* CSCIB;

SCIC_Class* CSCIC;

int main(void){

CSCIA = new SCIA_Class();

CSCIB = new SCIB_Class();

CSCIC = new SCIC_Class();

}

2)

int main(void){

SCIA_Class CSCIA;

SCIB_Class CSCIB;

SCIC_Class CSCIC;

}