cancel
Showing results for 
Search instead for 
Did you mean: 

STO_PLL_CalcAvrgMecSpeedUnit() overflows in certain conditions

BTrem.1
Senior II

The code in mc_tasks.c in routine void TSK_MediumFrequencyTaskM1(void) calls

bool IsSpeedReliable = STO_PLL_CalcAvrgMecSpeedUnit (&STO_PLL_M1, &wAux);

This function computes the average mechanical velocity, among other things. The above function is not in the distributed source code, but is in the compiled object library. The source code is available in the final release of ST code MC_SDK_5.Y.4, but converting to this release from 5.4.4 would be a very large task.

In speed_torque_cntrl.c in routine int16_t STC_CalcTorqueReference( SpeednTorqCtrl_Handle_t * pHandle) the function SPD_GetAvrgMecSpeedUnit(pHandle->SPD ) is called to get the average velocity. This routine accesses the velocity from a structure updated from the first function above. This routine is apparently overflowing as indicated by logging the return data shown below.

0693W00000NrGr9QAF.png 

The ST code in this function uses a variable int32 wAux that overflows. The beginning values fits int32 and the final value fits int16 but an intermediate value overflows int32. My revised solution was to make wAux int64_t.

The solution to not having the full source code in SDK_5.4.4 was to copy the function source code from SDK 5.Y.4 and put it in source file sto_pll_speed_pos_obs.c but not declare it __weak. In this manner the new function will replace the compile object code and the new code can be corrected as described above.

With this change the overflow limit speed was changed from an electrical speed of 327Hz to a much higher level, limited by other restrictions not encountered.

In the original trouble spot the overflow limit was 2^31. Using a speed resolution of _001Hz == 100 the electrical frequency at which overflow occurs is 2^31/(100 * 2^15) = 327.68 Hz.

0 REPLIES 0