• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 209 views
  • Users 0 members are here
Support feedback
Options
Options

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.

LAUNCHXL-F280049C: SDK 4.01 estimator ignores inline calls

Genatco
Guru 55553 points
Part Number: LAUNCHXL-F280049C

Hello, 

Edit: SDK4.01 Eabi/COF projects both have the same issue of inline estimator calls failing to access ROM functions.

I have attempted to unwind the SDK(FOC) eabi code as to choose several non-defined motors within functions in a C file via an external HID device. It was working up to the point that ROM estimator started to ignore the motor is ID (true) inline calls shown below. Oddly, only motorVars.Ls_d_H~ ~.Ls_q_H are being over written (0.0) just after userParams._Ls_d_H ~._Ls_q_H updated debug (yellow box). Even though the estimator is told motor has been ID via inline calls, estimator still tries to ID motor every time isLAB_07 speed control object. 

Even if I comment global updates 2 estimator inductance motorVars.Ls_q_H ~.Ls_d_H bottom (labs.h), still being over written 0.0. This seems to be an issue with the ROM code enabling motor ID switch by default and ignoring motor ID (true) inline calls flag so the controller is not being enabled or ever updated. Every time (motorVars.flagRunIdentAndOnLine) is enabled the estimator tries to ID the motor. Is there some way to stop od ID behavior or the Fast ROM library fixes this issue? 

Note: Bypass ID flag or #define (user.h) are not being enabled by inline estimator calls I can find in the project. There are two user.c defines for motor ID process below, 2 inductance overloads being commented seem to be part of the reason estimator ignores motor ID (true). Also replaces motorVars.Ls_d_H ~Ls_q_H as 0x0. Happen in debug view immediately after motorVars.~ have been triggered via exported structs of userParams.~

Why is the ROM estimator taking control away from the application is the even bigger question? 

(user.c) //userParams.motor_Ls_d_H = (float32_t)1.0e-6;
(user.c) //userParams.motor_Ls_q_H = (float32_t)1.0e-6;

/* set the userParam flag */
userParams.flag_bypassMotorId = true;

Inlines placed top of main.c isLAB_07:

//! \brief Sets the motor identified flag state in the estimator
//! \param[in] handle The estimator (EST) handle
//! \param[in] state The desired state, e.g. identified true
EST_setFlag_motorIdentified(estHandle, true);

//! \brief Gets the motor identified flag state in the estimator
//! \param[in] handle The estimator (EST) handle
//! \return The state of the motor identified flag
motorVars.flagMotorIdentified = EST_getFlag_motorIdentified(estHandle);

 

  • 0
    TI__Guru 50470 points

    Hi,

    The subject matter expert is out of office this week. please expect response by next week.

    Regards, Santosh

  • 0 in reply to Santosh Jha
    Guru 55553 points

    Hi Santosh,

    I had assumed as much being the holidays. At one point it was working with #defines (user.h) entering single motor parameters. Back tracking user.h code history still has the same ID problems. Both user/motor parameter structs are being loaded into LSRAM in the same sections. The estimator appears to be loading 0.0 on top of the 2 run state values.

    Oddly if I force the controller setup early in main.c it still over-loads motorVars 2 correct inductance values with 0.0. 

  • 0 in reply to Genatco
    TI__Guru 50470 points

    Hi GI,

    II am not familiar with motor control sdk.  have notified another if she can help in this while Yanming is out of office.

    Regards, Santosh

  • 0 in reply to Santosh Jha
    Guru 55553 points

    Below are some captures seem to indicate the inline calls to estimator writes and reads of any input values don't even work. The user.h motor #defines values were propagated via struct triggering pointers, thus reading values loaded by #pragma RAM seemingly being linked but not by the pointers, rather the compilers linker.

    When the link symbols (->) are removed and UserMotor #defines replaced by float32_t variables, the inline calls estimator ROM functions fail to work at all. The control object is also broken, so it reasons the motor has not been previously ID. The compound variable (myVar.structMember = variable;) are RAM type #prama of the same struct/s and should have similar behavior as (->) since userParams are all being loaded verified do exist in the #pragma RAM space. 

  • +1 in reply to Genatco
    Guru 55553 points

    Problem was isolated 2 weeks later SDK2.01 (motorIdentifed) bool flag (userParams.h) struct stops all other estimator calls from working, oddly right after userParams.LS_d/q_H were linked far above bool flag in the struct listing. The mind-blowing part being the Identified flag was added Universal Motor Control SDK userParams.h just under BypassMotorIdentified bool flag. I don't believe I moved the Identified flag from the SDK 4.0 UserParams.h struct. Yet what does that have to do with motorVars._LS_d/q_H reading 0.0?

    This issue seems like compiler fails to sort struct tag key element list to find a named variable in another C module reference by #include. So it seems it must have stopped compiling but only in that struct listing where it expected to find the bool flag. Hence my reason to believe removing the pUserParams-> pointers was to blame since it was working after I stopped CCS debug, the next time loaded firmware it did not work after changing the pointes to linked type variables. 

     The other note is fastfulllibeabi.lib replaced ROM symbols produce incorrect values motorVars.LS_d/q_H  in SDK 4.01 isLAB_07.