- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
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);
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.
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.
