CCS/TMS320F28335: F28335 EBSS SIZE

Ehsan,

RAML4 is OK, as long as you don't declare same memory region or a part of this memory region (in our example from 0x00B000 to 0x00D000) in somewhere else in cmd file (in page 0 & 1). An overlapping memory could be problem, but I think the compiler or linker will throw an error/warning in that case.

About the PI output, assuming you keep the PI parameters constant, the only difference could come from the error signal, which basically "CurrentReference - ActualCurrent" in your FOC motor control application. Make sure that you give the same reference for all your runs and also make sure that you read the motor currents correctly. Changing PI parameters and reference or having a problem in motor current reading could cause the PI controller produce different output. Moreover, you will have an inevitable noise on the current reading, so don't expect the PI controller to produce exactly same output even everthing is same and proper.

Regards,
Hakan

Thank you very much Hakan for your detailed response. 

I see your point about the overlapping. Actually, this is the linker configuration that I have for memory.

MEMORY
{
PAGE 0 :
/* BEGIN is used for the "boot to SARAM" bootloader mode */

BEGIN : origin = 0x000000, length = 0x000002 /* Boot to M0 will go here */
RAMM0 : origin = 0x000050, length = 0x0003B0
RAML0 : origin = 0x008000, length = 0x001000
RAML1 : origin = 0x009000, length = 0x001000
RAML2 : origin = 0x00A000, length = 0x001000
RAML3 : origin = 0x00B000, length = 0x001000
ZONE7A : origin = 0x200000, length = 0x00FC00 /* XINTF zone 7 - program space */
CSM_RSVD : origin = 0x33FF80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
CSM_PWL : origin = 0x33FFF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */
ADC_CAL : origin = 0x380080, length = 0x000009
RESET : origin = 0x3FFFC0, length = 0x000002
IQTABLES : origin = 0x3FE000, length = 0x000b50
IQTABLES2 : origin = 0x3FEB50, length = 0x00008c
FPUTABLES : origin = 0x3FEBDC, length = 0x0006A0
BOOTROM : origin = 0x3FF27C, length = 0x000D44

PAGE 1 :
/* BOOT_RSVD is used by the boot ROM for stack. */
/* This section is only reserved to keep the BOOT ROM from */
/* corrupting this area during the debug process */

BOOT_RSVD : origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAML4 : origin = 0x00A000, length = 0x003000
RAML5 : origin = 0x00D000, length = 0x001000
RAML6 : origin = 0x00E000, length = 0x001000
RAML7 : origin = 0x00F000, length = 0x001000
ZONE7B : origin = 0x20FC00, length = 0x000400 /* XINTF zone 7 - data space */
}

SECTIONS
{
/* Setup for "boot to SARAM" mode:
The codestart section (found in DSP28_CodeStartBranch.asm)
re-directs execution to the start of user code. */
codestart : > BEGIN, PAGE = 0
ramfuncs : > RAML0, PAGE = 0
.text : > RAML1, PAGE = 0
.cinit : > RAML0, PAGE = 0
.pinit : > RAML0, PAGE = 0
.switch : > RAML0, PAGE = 0

.stack : > RAMM1, PAGE = 1
.ebss : > RAML4, PAGE = 1
.econst : > RAML5, PAGE = 1
.esysmem : > RAMM1, PAGE = 1

IQmath : > RAML1, PAGE = 0
IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD

FPUmathTables : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

DMARAML4 : > RAML4, PAGE = 1
DMARAML5 : > RAML5, PAGE = 1
DMARAML6 : > RAML6, PAGE = 1
DMARAML7 : > RAML7, PAGE = 1

ZONE7DATA : > ZONE7B, PAGE = 1

.reset : > RESET, PAGE = 0, TYPE = DSECT /* not used */
csm_rsvd : > CSM_RSVD PAGE = 0, TYPE = DSECT /* not used for SARAM examples */
csmpasswds : > CSM_PWL PAGE = 0, TYPE = DSECT /* not used for SARAM examples */

/* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */
.adc_cal : load = ADC_CAL, PAGE = 0, TYPE = NOLOAD

}

With this configuration, it seems to me that my memory modification produces an overlap between RAML4 in page 1 (from 0x00A000 to 0x00D000) and RAML1 (from 0x00A000 to 0x00B000) and RAML2 (from 0x00B000 to 0x00C000) on page 0. Can this overlap between page 0 and page 1 cause this problem that I have on my FOC and PI paraemeters? If you guess so, what configuration do you recommend for RAML4 on page 1 or the whole page 1 memory, as I need that much space (0x003000) on RAML4 of page 1. 

For PI parameters, the PI controller on the motor speed produces the q-axis current reference and then I have another PI on q-axis current. I have tested the actual currents a few times and it seems that the currents are being read continuously. Sometimes, the output of speed PI controller (q-axis current reference) reaches the limit and sometimes it goes to the value and keeps tracking the proper value, given the exact situation and parameters. But, you point on noises makes sense. However, I still have doubt on memory configuration. I would appreciate if you please help me. 

Thanks,

Ehsan,

You are right. You have overlapping memories and that is a problem. You have separate them and make sure that they are not overlapping. Unfortunately, I can not tell you the right memory allocation, because it totally depends on your application. There is no perfect or general solution for memory management. But I can guide you to arrange the memory in a right way. Please follow these steps:

1) First open the datasheet of your DSP (F28335 in our example), and find the memory map. Note all the RAM areas that you could possibly use. I always have a printed out version of the memory map on my wall. It is useful. There are also template cmd files in ControlSuite and C2000Ware that include all RAM locations of F28335. Have a quick search for them. You can use those templates as a starting point of your new cmd file.

2) Find the .map file, which is generated by CCS during compilation. It is a treasure map. It contains very useful information like section sizes, used and unused memory locations, size of functions/variables, location of them, etc. The .map file is in the same directory of your .out file. Open it up and note all the section sizes you have to allocate.

3) Now you know your RAM locations and sizes from the memory map and sections sizes from the .map file. it is time to change RAM definitions in PAGE 0 and 1 in the cmd file. You have to change it so that there will no overlapping memory definition and all sections must fit into selected RAM area. It is like tetris game, but if you are successful, you will have your new cmd file.

I also suggest you to make a small test with a simple program after you have the new cmd file . You can blink some leds or run a PI filter with the same error, so that you will have always the same output. Make sure that the program runs OK with you new cmd file. After that, try to run FOC. Because FOC can be tricky for the first time. And it is hard to identify whether you have an error on your cmd file or on FOC algorithm, if you run them both. Divide & conquer. It is easier.

If you are interested about sections and cmd files etc., please have a look at those:

http://www.ti.com/lit/ug/spru513p/spru513p.pdf

http://www.ti.com/lit/ug/spru514p/spru514p.pdf

Good luck,
Hakan

Hakan,

Thank you so much for your detailed response.

I found the .map file and here is a copy of the part that shows memory map of page 0 and 1:

PAGE 0:
BEGIN 00000000 00000002 00000002 00000000 RWIX
RAMM0 00000050 000003b0 00000000 000003b0 RWIX
RAML0 00008000 00001000 00000cbb 00000345 RWIX
RAML1 00009000 00001000 00000cd8 00000328 RWIX
RAML2 0000a000 00001000 00000000 00001000 RWIX
RAML3 0000b000 00001000 00000000 00001000 RWIX
ZONE7A 00200000 0000fc00 00000000 0000fc00 RWIX
CSM_RSVD 0033ff80 00000076 00000000 00000076 RWIX
CSM_PWL 0033fff8 00000008 00000000 00000008 RWIX
ADC_CAL 00380080 00000009 00000007 00000002 RWIX
IQTABLES 003fe000 00000b50 00000000 00000b50 RWIX
IQTABLES2 003feb50 0000008c 00000000 0000008c RWIX
FPUTABLES 003febdc 000006a0 00000000 000006a0 RWIX
BOOTROM 003ff27c 00000d44 00000000 00000d44 RWIX
RESET 003fffc0 00000002 00000000 00000002 RWIX

PAGE 1:
BOOT_RSVD 00000002 0000004e 00000000 0000004e RWIX
RAMM1 00000400 00000400 00000400 00000000 RWIX
DEV_EMU 00000880 00000180 000000d0 000000b0 RWIX
FLASH_REGS 00000a80 00000060 00000008 00000058 RWIX
CSM 00000ae0 00000010 00000010 00000000 RWIX
ADC_MIRROR 00000b00 00000010 00000010 00000000 RWIX
XINTF 00000b20 00000020 0000001e 00000002 RWIX
CPU_TIMER0 00000c00 00000008 00000008 00000000 RWIX
CPU_TIMER1 00000c08 00000008 00000008 00000000 RWIX
CPU_TIMER2 00000c10 00000008 00000008 00000000 RWIX
PIE_CTRL 00000ce0 00000020 0000001a 00000006 RWIX
PIE_VECT 00000d00 00000100 00000100 00000000 RWIX
DMA 00001000 00000200 000000e0 00000120 RWIX
MCBSPA 00005000 00000040 00000025 0000001b RWIX
MCBSPB 00005040 00000040 00000025 0000001b RWIX
ECANA 00006000 00000040 00000034 0000000c RWIX
ECANA_LAM 00006040 00000040 00000040 00000000 RWIX
ECANA_MOTS 00006080 00000040 00000040 00000000 RWIX
ECANA_MOTO 000060c0 00000040 00000040 00000000 RWIX
ECANA_MBOX 00006100 00000100 00000100 00000000 RWIX
ECANB 00006200 00000040 00000034 0000000c RWIX
ECANB_LAM 00006240 00000040 00000040 00000000 RWIX
ECANB_MOTS 00006280 00000040 00000040 00000000 RWIX
ECANB_MOTO 000062c0 00000040 00000040 00000000 RWIX
ECANB_MBOX 00006300 00000100 00000100 00000000 RWIX
EPWM1 00006800 00000022 00000022 00000000 RWIX
EPWM2 00006840 00000022 00000022 00000000 RWIX
EPWM3 00006880 00000022 00000022 00000000 RWIX
EPWM4 000068c0 00000022 00000022 00000000 RWIX
EPWM5 00006900 00000022 00000022 00000000 RWIX
EPWM6 00006940 00000022 00000022 00000000 RWIX
ECAP1 00006a00 00000020 00000020 00000000 RWIX
ECAP2 00006a20 00000020 00000020 00000000 RWIX
ECAP3 00006a40 00000020 00000020 00000000 RWIX
ECAP4 00006a60 00000020 00000020 00000000 RWIX
ECAP5 00006a80 00000020 00000020 00000000 RWIX
ECAP6 00006aa0 00000020 00000020 00000000 RWIX
EQEP1 00006b00 00000040 00000040 00000000 RWIX
EQEP2 00006b40 00000040 00000040 00000000 RWIX
GPIOCTRL 00006f80 00000040 0000002e 00000012 RWIX
GPIODAT 00006fc0 00000020 00000020 00000000 RWIX
GPIOINT 00006fe0 00000020 0000000a 00000016 RWIX
SYSTEM 00007010 00000020 00000020 00000000 RWIX
SPIA 00007040 00000010 00000010 00000000 RWIX
SCIA 00007050 00000010 00000010 00000000 RWIX
XINTRUPT 00007070 00000010 00000010 00000000 RWIX
ADC 00007100 00000020 0000001e 00000002 RWIX
SCIB 00007750 00000010 00000010 00000000 RWIX
SCIC 00007770 00000010 00000010 00000000 RWIX
I2CA 00007900 00000040 00000022 0000001e RWIX
RAML4 0000a000 00003000 00002a58 000005a8 RWIX
RAML5 0000d000 00001000 00000100 00000f00 RWIX
RAML6 0000e000 00001000 00000000 00001000 RWIX
RAML7 0000f000 00001000 00000000 00001000 RWIX
ZONE7B 0020fc00 00000400 00000000 00000400 RWIX
CSM_PWL 0033fff8 00000008 00000008 00000000 RWIX
PARTID 00380090 00000001 00000001 00000000 RWIX


I found also the memory map datasheet of f28335 and printed it :), I have a question that might be so obvious, but since I am not that much experienced in computer architecture, I need to ask it. The part that I have problem with is the memory for data space, which is defined on page 1 and on RAML4. Based on above .map file, the currently used space for RAML4 is 00002a58, and I have determined the origin of it as 0000A000. However, I see on the datasheet that origin of RAML4 is 0000C000. Is it fine that I changed the origin of RAML4, assuming that there is no overlap on the memory? I mean are we allowed to change the origin of a SARAM (L0-L7) based on our need? Or we should keep the origin as the datasheet says, and try to combine them for different sections? For example combining RAML4 and RAML5 and using them for .ebss to make more space.

I do not have any experience on this part, and I have been using the template for memory allocation for about two years, and haven't had any problem with it so far. But, right now I see that I need to modify the linker based on my need. And this is why I am raising these questions that might be so clear to you.

Thanks a lot in advance,

Thanks Christopher for your response. I did so :)

Hi Hakan,

As you recommended, I read those documents .map file. So, this is the configuration that I made for linker. From the size point of view, program/variables/functions and etc fit into the new configuration and there is no more error in my cmd file when I build my project. I changed the origin and length of RAML1, L2, and L3 of page 0 so that I can make the origin of RAML4 of page 1 from 0x00A000 and have it length equal to 0x003000. I am copying my new cmd file here:

MEMORY
{
PAGE 0 :
/* BEGIN is used for the "boot to SARAM" bootloader mode */

BEGIN : origin = 0x000000, length = 0x000002 /* Boot to M0 will go here */
RAMM0 : origin = 0x000050, length = 0x0003B0
RAML0 : origin = 0x008000, length = 0x001000
RAML1 : origin = 0x009000, length = 0x000D00
RAML2 : origin = 0x009D00, length = 0x000100
RAML3 : origin = 0x009E00, length = 0x000100
ZONE7A : origin = 0x200000, length = 0x00FC00 /* XINTF zone 7 - program space */
CSM_RSVD : origin = 0x33FF80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
CSM_PWL : origin = 0x33FFF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */
ADC_CAL : origin = 0x380080, length = 0x000009
RESET : origin = 0x3FFFC0, length = 0x000002
IQTABLES : origin = 0x3FE000, length = 0x000b50
IQTABLES2 : origin = 0x3FEB50, length = 0x00008c
FPUTABLES : origin = 0x3FEBDC, length = 0x0006A0
BOOTROM : origin = 0x3FF27C, length = 0x000D44


PAGE 1 :
/* BOOT_RSVD is used by the boot ROM for stack. */
/* This section is only reserved to keep the BOOT ROM from */
/* corrupting this area during the debug process */

BOOT_RSVD : origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAML4 : origin = 0x00A000, length = 0x003000
RAML5 : origin = 0x00D000, length = 0x001000
RAML6 : origin = 0x00E000, length = 0x001000
RAML7 : origin = 0x00F000, length = 0x001000
ZONE7B : origin = 0x20FC00, length = 0x000400 /* XINTF zone 7 - data space */
}


SECTIONS
{
/* Setup for "boot to SARAM" mode:
The codestart section (found in DSP28_CodeStartBranch.asm)
re-directs execution to the start of user code. */
codestart : > BEGIN, PAGE = 0
ramfuncs : > RAML0, PAGE = 0
.text : > RAML1, PAGE = 0
.cinit : > RAML0, PAGE = 0
.pinit : > RAML0, PAGE = 0
.switch : > RAML0, PAGE = 0

.stack : > RAMM1, PAGE = 1
.ebss : > RAML4, PAGE = 1
.econst : > RAML5, PAGE = 1
.esysmem : > RAMM1, PAGE = 1

IQmath : > RAML1, PAGE = 0
IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD

/* Uncomment the section below if calling the IQNexp() or IQexp()
functions from the IQMath.lib library in order to utilize the
relevant IQ Math table in Boot ROM (This saves space and Boot ROM
is 1 wait-state). If this section is not uncommented, IQmathTables2
will be loaded into other memory (SARAM, Flash, etc.) and will take
up space, but 0 wait-state is possible.
*/
/*
IQmathTables2 : > IQTABLES2, PAGE = 0, TYPE = NOLOAD
{

IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)

}
*/

FPUmathTables : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

DMARAML4 : > RAML4, PAGE = 1
DMARAML5 : > RAML5, PAGE = 1
DMARAML6 : > RAML6, PAGE = 1
DMARAML7 : > RAML7, PAGE = 1

ZONE7DATA : > ZONE7B, PAGE = 1

.reset : > RESET, PAGE = 0, TYPE = DSECT /* not used */
csm_rsvd : > CSM_RSVD PAGE = 0, TYPE = DSECT /* not used for SARAM examples */
csmpasswds : > CSM_PWL PAGE = 0, TYPE = DSECT /* not used for SARAM examples */

/* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */
.adc_cal : load = ADC_CAL, PAGE = 0, TYPE = NOLOAD

}

Do you think from the memory architecture point of view, this configuration may not be right?

Thanks,

Thanks Hakan a lot!

Hi Hakan,

Regarding our recent discussion here, I modified the linker command another time, because it turned out that I need more space for text and ebss. But, when I change the linker command, I get completely different and weird results with exactly the same code and test!! This seems very weird to me. I am not sure what the problem could be, and here is the linker code. When I put length = 0x000D00 for RAML1 of page 0, I get results as I expect, but when I increase the length to 0x000D50, I get completely different results. When I again put length = 0x000D00 for the length of RAML1 of page0, I get again the results that I expect. 

MEMORY
{
PAGE 0 :
/* BEGIN is used for the "boot to SARAM" bootloader mode */

BEGIN : origin = 0x000000, length = 0x000002 /* Boot to M0 will go here */
RAMM0 : origin = 0x000050, length = 0x0003B0
RAML0 : origin = 0x008000, length = 0x001000
RAML1 : origin = 0x009000, length = 0x000D50
RAML2 : origin = 0x009D50, length = 0x000100
RAML3 : origin = 0x009E50, length = 0x000100
ZONE7A : origin = 0x200000, length = 0x00FC00 /* XINTF zone 7 - program space */
CSM_RSVD : origin = 0x33FF80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
CSM_PWL : origin = 0x33FFF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */
ADC_CAL : origin = 0x380080, length = 0x000009
RESET : origin = 0x3FFFC0, length = 0x000002
IQTABLES : origin = 0x3FE000, length = 0x000b50
IQTABLES2 : origin = 0x3FEB50, length = 0x00008c
FPUTABLES : origin = 0x3FEBDC, length = 0x0006A0
BOOTROM : origin = 0x3FF27C, length = 0x000D44

PAGE 1 :
/* BOOT_RSVD is used by the boot ROM for stack. */
/* This section is only reserved to keep the BOOT ROM from */
/* corrupting this area during the debug process */

BOOT_RSVD : origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAML4 : origin = 0x00A000, length = 0x003000
RAML5 : origin = 0x00D000, length = 0x001000
RAML6 : origin = 0x00E000, length = 0x001000
RAML7 : origin = 0x00F000, length = 0x001000
ZONE7B : origin = 0x20FC00, length = 0x000400 /* XINTF zone 7 - data space */
}

SECTIONS
{
/* Setup for "boot to SARAM" mode:
The codestart section (found in DSP28_CodeStartBranch.asm)
re-directs execution to the start of user code. */
codestart : > BEGIN, PAGE = 0
ramfuncs : > RAML0, PAGE = 0
.text : > RAML1, PAGE = 0
.cinit : > RAML0, PAGE = 0
.pinit : > RAML0, PAGE = 0
.switch : > RAML0, PAGE = 0

.stack : > RAMM1, PAGE = 1
.ebss : > RAML4, PAGE = 1
.econst : > RAML5, PAGE = 1
.esysmem : > RAMM1, PAGE = 1

IQmath : > RAML1, PAGE = 0
IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD

/* Uncomment the section below if calling the IQNexp() or IQexp()
functions from the IQMath.lib library in order to utilize the
relevant IQ Math table in Boot ROM (This saves space and Boot ROM
is 1 wait-state). If this section is not uncommented, IQmathTables2
will be loaded into other memory (SARAM, Flash, etc.) and will take
up space, but 0 wait-state is possible.
*/
/*
IQmathTables2 : > IQTABLES2, PAGE = 0, TYPE = NOLOAD
{

IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)

}
*/

FPUmathTables : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

DMARAML4 : > RAML4, PAGE = 1
DMARAML5 : > RAML5, PAGE = 1
DMARAML6 : > RAML6, PAGE = 1
DMARAML7 : > RAML7, PAGE = 1

ZONE7DATA : > ZONE7B, PAGE = 1

.reset : > RESET, PAGE = 0, TYPE = DSECT /* not used */
csm_rsvd : > CSM_RSVD PAGE = 0, TYPE = DSECT /* not used for SARAM examples */
csmpasswds : > CSM_PWL PAGE = 0, TYPE = DSECT /* not used for SARAM examples */

/* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */
.adc_cal : load = ADC_CAL, PAGE = 0, TYPE = NOLOAD

}

Ehsan,

I couldn't see the source of your problem at the first sight. But I suspect 2 things:

First, because of changing the length of a memory, some structures in your code could be misaligned. So, if you have pointer operations in your code, that can misbehave. Try to check variable addresses, if you have structures in your code. Check whether they increase as expected. Debug pointer operations and make sure that they execute correctly.

Secondly, maybe there is a mininum length that you can change in the memory sizes and 0x50 could be less than this mimimum size. Frankly, I don't think this is the case. But if I were you, I would keep miminum length as 0x100 (as a rule of thumb). If you need extra memory for .text, try to use RAM between 0x3F8000 and 3FC0000.

Regards,
Hakan

Thanks Hakan for your response.

Actually, I am not using any structure or pointer operation in my code.

For the memory length, none of the L0-L7 RAM memories length is less than 0x100; all of them are equal or larger than 0x100. It is weird that by changing the memory configuration (and avoiding memory overlap) the output of PI controllers reach the high limit and I guess this is the reason that I get different results. And when I undo the memory modification I get the results that I expected. However, anyhow I need to increase and change the memory configuration because I need to have more floating point variables. I have three doubts:

First, I have doubts on memory configuration, because changing the memory configuration leads to different results and this seems weird to me, because the PI controllers reach the limit value.

Second, I have floating point computations in my code; do I need to change or add any library for floating point computation? I check the value of float variables and they are actually float; but I was doubting maybe I need to do a change something. This is my first timed dealing with floating point variables in DSP and CCS.

Third, I copy the code that I have for my PI controllers; I implement the same code for PI in simulations and I get accurate results. But, this is my other doubt that something may be wrong with my PI.

e_w[0]=wref-nm_ave;
Iq[0]=Iq[1]+(Kpw+Kiw*Ts)*e_w[0]-Kpw*e_w[1];
Iq[1]=Iq[0];
e_w[1]=e_w[0];
Iqs=Iq[0];

Here, Iqs is the output of PI as the q-axis current reference and I put the limiter on this. Also, all the parameters in this part are float. So, when I change the memory configuration, Iqs gets a large value and reaches the upper limit. 

Thanks in advance,

Ehsan,

My mistake. With 0x100, I tried to say minimum resolution of memory. So, a memory length should be 0x100, 0x200, 0x300... etc for example.

Your PI code seems OK. In your tests, do you feed PI controller with a fixed error or with sensor values that can change over time (like current, temperature, etc). If the second one, try to feed it with a fixed value and observe the output.

About the libraries, if you use park, clarke transforms from TI library for your FOC operations, I think you should add IQ math library to your project. But I don't think this is the cause of your misbehaving program. Because if the compiler and linker could not find the library, they will probably throw an error.

Hakan

Ehsan,

I am happy that you solved your problem. Yes, initialization of parameters is very important. I have a habit to check occasionally all my variables are initialized in my code.

For the PI tuning, you can watch Dave Wilson's training videos, which are called 'Teaching Old Motors New Tricks'. Please google it, there are very useful.

Regards,
Hakan