TMS320F280049C: Launchpad: Instaspin FOC MOTORCONTROL SDK Lab03: Can't get datalog to work in lab 3.

Part Number: TMS320F280049C

Hi,

I am on LAB03 of the instapsin labs in the newer motorcontrol SDK.

I'm using CCS 9.0.1.

The datalog buffer size is 400 samples, but all of the buffer values always show zero except [399]

The same is true for datalogBuff1, datalogBuff2, datalogBuff3, datalogBuff4. For example, here is a readout in realtime from the expression viewer when debugging:

Inspecting the code, here is where in main i am assigning the desired variable addresses to the datalog pointers:

  

(for example, iptr[0] is now the foc angle.)

In the mainISR, DATALOG_updateWithDMA is called from datalog.h

In datalog.h, it seems like a value is only being assigned to datalogBuff1[399] because number is always = 399, and nothing happens with the other 399 values. Please help, am I missing something?

  • Please check if the .cmd file is changed. The datalog_data section must be in RAMGS0 if using DMA for datalog as below.

    datalog_data : > RAMGS0_A,   PAGE = 1

  • Thank you for the reply, Yanming. I will admit, I am a little new to CCS and my primary background is mechanical engineering.

    Here is what I have found:

    Looking at the Memory allocation tab, I found datalog_data taking up 3216 of RAMGS0_A:

    I am not sure how to check the proper .cmd file. Here are some of my project settings: the linker command file is empty in "general"

    the problem is the same for all labs. Datalog only shows an update on [399] on labs 3-8

  • Yanming,

    I'm sorry - I found the file. It's f28004x_ram_cpu_is_eabi.cmd.

    I found the line datalog_data   : > RAMGS0_A at the end of the file.

    I added the ", PAGE = 1" like you suggest and built and reloaded. 

    The problem is unchanged.

    I've attached the whole file below:

    /*
    // TI File $Revision: /main/3 $
    // Checkin $Date: Agu 1, 2017   13:45:43 $
    //
    // FILE:    F280049_RAM_CPU.cmd
    //
    // TITLE:   Linker Command File For F280049 examples that run out of RAM
    //
    //
    //          Keep in mind that L0,L1,L2,L3 and L4 are protected by the code
    //          security module.
    //
    //          What this means is in most cases you will want to move to
    //          another memory map file which has more memory defined.
    //
    */
    
    /*========================================================= */
    /* Define the memory block start/length for the F2806x
       PAGE 0 will be used to organize program sections
       PAGE 1 will be used to organize data sections
    
       Notes:
             Memory blocks on F280049 are uniform (ie same
             physical memory) in both PAGE 0 and PAGE 1.
             That is the same memory region should not be
             defined for both PAGE 0 and PAGE 1.
             Doing so will result in corruption of program
             and/or data.
    
             Contiguous SARAM memory blocks can be combined
             if required to create a larger memory block.
    */
    
    MEMORY
    {
    PAGE 0 :
    PAGE 1 :
       BEGIN           	: origin = 0x000000, length = 0x000002
       RESET            : origin = 0x3FFFC0, length = 0x000002
    
       RAMGS1_3         : origin = 0x00E000, length = 0x006000
       RAMLS4_7         : origin = 0x00A000, length = 0x002000
    
    /*   FLASHB0_SA		: origin = 0x080002, length = 0x00FFFE	*/	/* on-chip Flash */
    /*   FLASHB1_SA   	: origin = 0x090000, length = 0x010000	*/	/* on-chip Flash */
    
       BOOT_RSVD        : origin = 0x000002, length = 0x0000F3      /* Part of M0, BOOT rom will use this for stack */
       RAMM0_1        	: origin = 0x0000F5, length = 0x00070B
    
    /* CLA1             : origin = 0x001400, length = 0x000080	*/ /* Defined in headers cmd file*/
    
       RAMGS0_A         : origin = 0x00C000, length = 0x002000
    
       RAMLS0_1         : origin = 0x008000, length = 0x001000		/* Can't be used, reserved for FAST object */
       RAMLS2_3         : origin = 0x009100, length = 0x000F00		/* */
    
       CLA1MSGRAMLOW    : origin = 0x001480, length = 0x000080
       CLA1MSGRAMHIGH   : origin = 0x001500, length = 0x000080
    
    }
    
    SECTIONS
    {
       codestart        : > BEGIN,     		 ALIGN(4)
       .TI.ramfunc      : > RAMLS4_7,        ALIGN(4)
       .text            : > RAMGS1_3,        ALIGN(4)
       .cinit           : > RAMGS1_3,        ALIGN(4)
    
       .switch          : > RAMGS1_3,        ALIGN(4)
       .const           : > RAMGS1_3
       .data            : > RAMGS1_3, 		 ALIGN(4)
    
       .reset           : > RESET,           TYPE = DSECT
    
    	/* Digital Controller Library functions */
    	dclfuncs		: > RAMGS1_3
    	dcl32funcs		: > RAMGS1_3
    
       .stack           : > RAMM0_1
       .bss             : > RAMGS0_A
       .bss:output      : > RAMGS0_A
       .init_array      : > RAMGS0_A, 		 ALIGN(4)
       .sysmem          : > RAMGS0_A
    
       .bss_cla         : > RAMLS2_3
       ClaData          : > RAMLS2_3, 		 ALIGN=2
    
       Cla1Prog         : > RAMLS4_7
       Cla1Prog2        : > RAMLS4_7
    
    
       Cla1ToCpuMsgRAM  : > CLA1MSGRAMLOW
       CpuToCla1MsgRAM  : > CLA1MSGRAMHIGH
    
       .const_cla       : > RAMLS2_3
    
       .scratchpad      : > RAMLS2_3
    }
    
    SECTIONS
    {
    	sysctrl_data	: > RAMGS0_A
    	ctrl_data		: > RAMM0_1
    }
    
    SECTIONS
    {
    	datalog_data	: > RAMGS0_A, PAGE = 1
    	graph_data		: > RAMGS0_A
    }
    

  • Please change DLOG_TRANSFER_SIZE in datalog.h as below.

    #define DLOG_TRANSFER_SIZE      42       // [(MEM_BUFFER_SIZE/(BURST)]

  • This solved the problem. how can I adjust the datalog speed?

    My mistake earlier - The waveform I was looking was the RSONLINE excitation current.

    Thanks again!

  • You can't change the datalog updated speed directly, it's the fastest update speed. You can just decrease the speed by calling the DATALOG_updateWithDMA() and HAL_trigDlogWithDMA() in a lower frequency ISR.