- 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.
Tool/software:
Example project UMCSDK v5.03 is very difficult to compile when customer object uses same symbols as example code. Such as typedefs pointers MotorVars_M1 or userParams_M1 in custom C modules. However, UMCSDK v4.02 has no such symbols compile issues in very same custom C modules though UMCSDK v4.02 lacks user FAST versus ESMO clarity being intermingled code functions.
That being said, back tracking MCSDK v4.0 same custom modules LAB_is07. Speed mode fails to place estimator motor ID ROM call run functions (.scratchpad page 1) into SRAM memory locations starting at 0x00009000. Oddly, CCS debug memory browser addresses: 0x00009000 length (0xE) are all 0x0 256k page/s and the ROM Symbols ruin calls copy into SRAM never occurs at debug address (0x003EC9EE, 0x003ECF60, 0x003ECF6B, 0x003EBF39, 0x003EB581). Yet the memory map indicates addresses being occupied LSRAM symbol call run ROM functions shown below.
Hence motor ID and EST procedures assert but absolutely no trajectory increase as (pwmData.Vabc_pu) remains unchanged (0.0) or locks up (0.0, 0.0, -0.0). And motor ID PARK fails to return any useable data internal or external to any estimator calls. Seemingly any of the MCSDK v4.0 example projects with added ROM symbols library should be capable of motor ID process when staged properly to do so as in LAB_is05?
Why are the ROM call functions listed in CMD file not loading into SRAM is the bigger question? Odder yet the LAB_is07 speed code runs previously ID motor with user parameters up to trajectory speed as expected it should. Please find attached the memory map and CMD file where later added COF build (.scratchpad page 1 0x00009000) made absolutely no difference. The address patch is not required for eabi library project builds though even when the linker was is explicitly told where to load patches in LSRAM starting at 0x00009000 the ROM calls run code is never copied. How on earth is LAB_is07 Speed mode able to call EST functions from ROM? Yet motor ID code added to LAB_is07 fails miserably to do so?
Spent days trying to get UMCSDK v5.03 to compile after someone moved hal.h motor #defines into hal.obj, changed the structure from UMCSDK v4.02. That is a huge change to previous examples that compiled without symbol errors when customers code refers to userParams_M1 or motorVars_M1 new typedef structs. Moving the user motor #defines from hal.h into hal.obj causes perpetual 104 symbol missing errors. CCS v12.0 Index refuses to let go of earlier UMCSDK v4.02 #defines still being listed (hal.h) in the same project tree. The index will not update or rebuild with current project (UMCSDK v5.03) with (UMCSDK v4.02) seemingly when still in the same project tree. We don't delete any working project from the CCS project tree until newer TI example code builds correctly and works as expected.
is07_memory map .zipf28004x_flash_cpu_is_eabi.zip
patch_EST_Angle_run_patchable_address : origin = 0x009000, length = 0x00000e
patch_EST_Dir_run_patchable_address : origin = 0x00900e, length = 0x00000e
patch_EST_Eab_run_patchable_address : origin = 0x00901c, length = 0x00000e
patch_EST_Flux_ab_estFluxDot_patchable_address : origin = 0x00902a, length = 0x00000e
patch_EST_Flux_dq_run_patchable_address : origin = 0x009038, length = 0x00000e
patch_EST_Flux_run_patchable_address : origin = 0x009046, length = 0x00000e
patch_EST_Freq_run_patchable_address : origin = 0x009054, length = 0x00000e
patch_EST_Iab_run_patchable_address : origin = 0x009062, length = 0x00000e
patch_EST_Idq_run_patchable_address : origin = 0x009070, length = 0x00000e
patch_EST_Ls_run_patchable_address : origin = 0x00907e, length = 0x00000e
patch_EST_OneOverDcBus_run_patchable_address : origin = 0x00908c, length = 0x00000e
patch_EST_Rr_run_patchable_address : origin = 0x00909a, length = 0x00000e
patch_EST_RsOnLine_run_patchable_address : origin = 0x0090a8, length = 0x00000e
patch_EST_Rs_run_patchable_address : origin = 0x0090b6, length = 0x00000e
patch_EST_Vab_run_patchable_address : origin = 0x0090c4, length = 0x00000e
patch_EST_Vdq_run_patchable_address : origin = 0x0090d2, length = 0x00000e
patch_EST_runEst_patchable_address : origin = 0x0090e0, length = 0x00000e
Below text may explain why secure ROM code is not working via JTAG controls executed remotely by CAN, SCI, FSI or other peripherals. Yet MCSDK project LAB_is05 (motor ID) executes as expected via CCS debug script file or MCSDK GUI and bool flag state control with CCS debug real time mode selected.
Yet LAB_is07 Speed control executes Estimator same embedded secure ROM calls without XDS110 being connected to LaunchXL-49c. Hence the very perplexing question how?
• Secure ROM: This device also has secure ROM which is EXEONLY-protected. This ROM contains specific function for the user, provided by TI.
3.13.1 Functional Description The security module restricts the CPU access to on-chip secure memory and resources without interrupting or stalling CPU execution. When a read occurs to a secure memory location, the read returns a zero value and CPU execution continues with the next instruction. This, in effect, blocks read and write access to secure memories through the JTAG port or external peripherals.
Sadly, UMCSDK V4.0 & V5.03 only allow one motor to be valid in code or motor user parameters referenced within called functions. Oddly the control object mortorSetVars does not load via *pUserParms handles shown.
The UMCSDK example projects handles are not working when #defines are removed as multiple and independent motor functions loaded by *pUserParams to be stored into _FLASH memory by way of FAPI write storage MCSDK versions. Hence the reason to revert back MCSDK LAB_is7 and make the FAST ROM object preform motor ID process of LAB_is05 for any motor parameters repeatedly retrieved from FAPI storage. So, we added UMCSDK new CMPSS DACVAL-H/L over current detection into LAB_is07.c and that works great to set trip zone fault OVC into user motor parameters, will post it for other users.
Other compiled captures: No existing motor userParams are copied into motorVars structure, the most important ones, e.g.
motorVars.motor_ls_d_H, motorVars.motor_ls_q_H, motorVars.Rs_Ohm, motorVars.flux_VpHz, etc..
Last capture add pointer *motorSetVars and &motorsetVars, still No motor userParams are copied into motorVars for runtime or motor ID:
// initialize the private user parameters
USER_setParams_priv(&motorSetVars_M1); //obj->userParamsHandle
