This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HET_IDE: where is variable e_HETPROGRAM0_UN

Part Number: HET_IDE

I'm creating a HET program for RM57LCxxx controller,

and in the assmembled .h file, there's a line:

extern volatile HETPROGRAM0_UN e_HETPROGRAM0_UN;

the structure HETPROGRAM0_UN  contains the structure of my program.

where is the location of that variable defined?

  • Jan,

    If you are looking at the HAHSCPTO TI design, then it's going to be in the bottom of the linker command file

    /* Misc */

    /* USER CODE BEGIN (8) */
    e_HETPROGRAM5_UN = 0xff440000;
    e_HETPROGRAM6_UN = 0xff440000;
    e_HETPROGRAM7_UN = 0xff440000;/* USER CODE END */

    So the symbols are defined at link time to point to the HET RAM.

    If you look above it seems odd because it looks like all three programs are pointing to the same memory.

    But then if you look into the 'pto_common' folder of the TI design CCS workspace,
    there are four different programs there. The first is 'pto_null' and I just make this #1 and give it to
    HalCoGen to load. This program does nothing, so that the HET get's fully initialized but it's running
    'null' code with all IO 3-stated as the HalCoGen init completes.

    #5, #6 and #7 are three programs "pto_countdir", "pto_cwccw", and "pto_quadrature".

    These three programs share common portions of code for generating the step timing, but each has it's own
    output 'encoder' so that 'countdir' outputs an edge on every step plus a level indicating direction (forward/backward).
    pto_cwccw generates edges on one pin to step forward, and steps on another pin for steps backward.
    'pto_quadrature' generates a quadrature encoded output ... you should be able to drive an 'eQEP' from this ;)

    The program you select (#5, #6, or #7) is loaded by the function:
    ptoRetVal_t ptoInit(ptoInst_t ptoNum, ptoMode_t ptoMode)

    You can see that it copies one of the HET programs from *flash* into RAM during init depending on the mode...

    case ptoModeCountDir:
    g_ptoMode[pto1] = ptoModeCountDir;
    (void)memcpy((void*)hetRAM2, (void*)HET_INIT5_PST, sizeof(HET_INIT5_PST));
    case ptoModeCwCcw:
    g_ptoMode[pto1] = ptoModeCwCcw;
    (void)memcpy((void*)hetRAM2, (void*)HET_INIT6_PST, sizeof(HET_INIT6_PST));
    case ptoModeQuadrature:

    So these things above are the load addresses of the HET programs (stored in FLASH) being copied to hetRAM2.

    However to *interact* with the program once it is loaded in the HET RAM, you need the structure
    'e_HETPROGRAMx_UN' pointing to the *run* address of the HET program because the data fields of the HET instructions mimic the functionality of control registers..

    So if you look at 'ptoStart' you can see:
    case ptoModeCountDir:
    e_HETPROGRAM5_UN.Program5_ST.P1_UPD_A_5.memory.data_word = PTO_STATE_ACTIVE;

    Writes a location in HET RAM that is used by the program to decide if it should run or just idle...

    Another example is in 'ptoCmdSubmit' .. the command requires 2 words so these are written to the
    simulated 'command buffer' registers:
    case ptoModeCountDir:
    pBuf0 = &e_HETPROGRAM5_UN.Program5_ST.P1_BUF0_5.memory.data_word;
    pBuf1 = &e_HETPROGRAM5_UN.Program5_ST.P1_BUF1_5.memory.data_word;
    while ((*pBuf1 & PTO_CMD_NEW) != 0);
    *pBuf0 = cmd.ptoCmdBuf0;
    *pBuf1 = cmd.ptoCmdBuf1;

    The 'while' waits on a bit being cleared in the previously submitted command, ... this bit is set in the command you submit and cleared by HET after it has consumed both command words and therefore it is safe to write a new command into these buffer locations...

    Anyway hope that helps ....

    One more thing, you need to rebuild the HET programs from HAHSCPTO to spin the motor.

    The HAHSCPTO code examples I think drive pins 1 and 3 because they are very easy to get to on that probing board I built, but to drive the motor you want:

    ; Pin Definitions
    ; These can be redefined to match your target hardware.
    ; If run on N2HET1 (N2HETx where x=1), then pin 0 is N2HET1[0].
    ; If run on N2HET2 (N2HETx where x=2), then pin 0 is N2HET2[0].
    PIN_P1_OA .equ 4 ;P1_OA on N2HETx[4]
    PIN_P1_OB .equ 9 ;P1_OB on N2HETx[9]

    At least this is what I see in the code our intern did...

    Also I think you want the 'count/dir' mode because that is what the DRV chip takes ...

    Best Regards,
  • Hi Jan,

    Did Anthony's post help resolve the issue?
  • Yes. Success! It works - I'm using HET1 so I have this code

    /* USER CODE BEGIN (8) */
    /* this is the address of hetRAM1 */
    e_HETPROGRAM5_UN = 0xff460000;
    e_HETPROGRAM6_UN = 0xff460000;
    e_HETPROGRAM7_UN = 0xff460000;
    /* USER CODE END */

    I'm using a DRV8711 boosterpack, and need NHET1-4 and 9

    PIN_P1_OA .equ 4 ;P1_OA on N2HETx[4] 
    PIN_P1_OB .equ 9 ;P1_OB on N2HETx[9]

    (example uses het2, I use het1, so I had to assemble the default het code script pto_null.het with -n0 parameter)

    result captured with a logic analyzer (trapezoid example with the count/dir het code referenced by Anthony above):