[参考译文] LAUNCHXL-F280049C：UMCSDK v5.03编译错误&amp；MCSDK4.0电机 ID 符号从 LSRAM 中缺少运行代码

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1495683/launchxl-f280049c-umcsdk-v5-03-compile-errors-mcsdk4-0-motor-id-symbols-run-code-missing-from-lsram

器件型号：LAUNCHXL-F280049C

工具与软件：

当客户对象使用与示例代码相同的符号时、示例项目 UMCSDK v5.03很难编译。类型定义指针 MotorVars_M1或 userParams_M1等类型定义 C 模块中的类型定义指针。但是、尽管 UMCSDK v4.02缺少用户速度快、而 eSMO Clarity 需要混合代码函数、但 UMCSDK v4.02在完全相同的定制 C 模块中不会出现此类符号编译问题。

话虽如此、反向跟踪 MCSDK v4.0相同的自定义模块 lab_is07。速度模式无法将估算器电机 ID ROM 调用运行函数(.scratchpad 页1)放入从0x00009000开始的 SRAM 存储器位置。奇怪的是、CCS 调试存储器浏览器地址：0x00009000长度(0xE)全部为0x0 256k 页/秒、ROM 符号破坏调用复制到 SRAM 永远不会发生在调试地址(0x003EC9EE、0x003ECF60、0x003ECF6B、0x003EBF39、0x003EB581)。但存储器映射表示正在占用的 LSRAM 符号调用运行 ROM 函数、如下所示。

因此、电机 ID 和 EST 过程断言、但绝对不会因(pwmData.Vabc_pu)保持不变(0.0)或锁定(0.0、0.0、-0.0)而增加轨迹。电机 ID 停止无法将任何可用数据返回到任何估算器调用的内部或外部。似乎任何添加了 ROM 符号库的 MCSDK v4.0示例项目都应该能够在合理分级后实现电机 ID 过程、如在 lab_is05中那样？

为什么 CMD 文件中列出的 ROM 调用函数没有加载到 SRAM 中才是更大的问题？订购之前的 lab_is07速度代码运行 ID 电机(用户参数高达预期的轨迹速度)。请查看随附的存储器映射和 CMD 文件、其中稍后添加的 COF 构建(.scratchpad page 1 0x00009000)完全没有区别。虽然 eabi 库工程构建不需要地址补丁、但即使链接器被明确告知要在 LSRAM 中从0x00009000开始从哪里加载补丁、ROM 调用运行代码也绝不会复制。 lab_is07速度模式如何从 ROM 调用 EST 函数？然而、添加到 Lab_is07的电机 ID 代码无法错误地做到这一点？

在有人将 hal.h 电机#defines 移动到 hal.obj 后、我们花了数天尝试让 UMCSDK v5.03进行编译、更改了 UMCSDK v4.02的结构。当客户代码引用 userParams_M1或 motorVars_M1新 typedef 结构时、对先前编译的示例而言、没有符号错误、这是一个巨大变化。将用户电机#defines 从 hal.h 移动到 hal.obj 会导致永久性104符号缺失错误。 CCS v12.0索引拒绝放弃先前的 UMCSDK v4.02 #defines、仍在同一项目树中列出(hal.h)。当当前工程(UMCSDK v5.03)似乎仍在同一工程树中时、索引不会更新或重新编译、(UMCSDK v4.02)看起来是相同的。直到正确构建更新的 TI 示例代码并按预期工作之后、我们才会从 CCS 工程树中删除任何工作工程。

e2e.ti.com/.../is07_5F00_memory-map-.zipe2e.ti.com/.../f28004x_5F00_flash_5F00_cpu_5F00_is_5F00_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

7 个月前

0 admin 7 个月前

TI__Guru**** 2463330 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

下面的文本可能会解释为什么安全 ROM 代码无法通过 CAN、SCI、FSI 或其他外设远程执行的 JTAG 控制正常工作。然而、 MCSDK 工程 lab_is05 (电机 ID)会通过 CCS 调试脚本文件或 MCSDK GUI 和 bool 标志状态控制(选择 CCS 调试实时模式)按预期执行。

然而、lab_is07速度控制在 XDS110未连接到 LaunchXL-49C 的情况下执行估算器相同的嵌入式安全 ROM 调用。因此,这是一个非常令人困惑的问题,如何?

•安全 ROM：该器件还具有受 EXEONLY 保护的安全 ROM。此 ROM 包含 TI 为用户提供的特定功能。

3.13.1功能说明安全模块限制 CPU 对片上安全存储器和资源的访问、而不中断或停止 CPU 执行。当读取到安全存储器位置时、读取返回零值、CPU 继续执行下一条指令。这可以有效阻止通过 JTAG 端口或外设对安全存储器的读取和写入存取。

0 admin 7 个月前

TI__Guru**** 2463330 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

遗憾的是、UMCSDK V4.0和 V5.03仅允许一个电机在被调用函数内引用的代码或电机用户参数中有效。奇怪的是、控制对象 mortorSetVars 不通过所示的*pUserParms 句柄加载。

当#define 通过* pUserParams 加载的多个独立电机函数(通过 FAPI 写存储 MCSDK 版本存储到_flash 存储器)进行删除时、UMCSDK 示例工程句柄不起作用。因此、需要针对从 FAPI 存储中重复检索到的任何电机参数恢复 MCSDK lab_is7并使快速 ROM 对象执行 lab_is05的电机 ID 过程。因此、我们将 UMCSDK 新的 CMPSS DACVAL-H/L 过流检测功能添加到 lab_is07.c 中、并且非常适合将跳闸区故障 OVC 设置到用户电机参数中、还会将其发布给其他用户。

其他已编译的捕获结果：不会将现有电机 userParams 复制到 motorVars 结构中、即最重要的结构

motorVars.motor_ls_d_H、 motorVars.motor_ls_q_H、motorVars.motorVars.flux_VpHz Rs_Ohm 等。

上次捕获添加指针* motorSetVars 和 motorsetVars、仍不会将电机 userParams 复制到 motorVars 中以表示运行时或电机 ID：

//初始化私有用户参数
USER_setParams_priv (&motorSetVars_M1)；//obj->userParamsHandle

0 admin 7 个月前

TI__Guru**** 2463330 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

UMCSDK v4.02存在的问题：用于存储 userParams_M1的* pUserParms 指针的#pragma 使用了外部空指针(user_common.h)到#pragma 段、而不是函数。如果我们按 CTRL 键、请单击下面的 extern 函数 void 并指向任何内容。

因此、任何人都可能认为它指向现有的函数调用。因此、请确保#pragma 确实复制到内存部分、因为当针对 GUI 控件调用的单个用户电机的多个函数移除用户电机#define 时、根本不会发生这种情况。私有指针* pUserParams 必须由链接器链接、该链接器在 UMCSDK v5.03示例工程中看起来运行得更好。

供参考定制 PCB 用户：任何尝试通过 SCI、CAN 或其他 GUI 控制台控制#define PWM 中断节拍(3)的速度对于电机 ID 过程而言过快。必须在 GUI 控制 LCD 文本和数字框的反馈中添加几个延迟。设计人员必须加快每个部分中的状态机等待时间、例如 Rs_Ohms、Ro/L、ls_d/q_H 等电机在 RatedFlux_OL 和 Ls 期间保持运行。奇怪的是、电机转子通常会停止旋转或只是通过 CCS 调试和定制 PCB 摆动电机 ID。当 MCU SCI 运行时、可以独立模式电机绝不会停止或摆动(振动)转子轴。

监测 SCI 时、并行 CCS 调试中的 GUI 估算状态变化 ls_d/q_H 会生成奇数个电感值和 Rs_Ohms 值。

// **************************************************************************
// the functions
//! \brief Sets the private user parameter values
//! \param[in] pUserParams The pointer to the user param structure
extern void cla_USER_setParams_priv(USER_Params *pUserParams);

//! \brief Sets the private user parameter values
//! \param[in] pUserParams The pointer to the user param structure
//! Links the pointer (*pUserParams) motor1_drive.c
//! #pragma DATA_SECTION(userParams_M1,"user_data");
//! USER_Params userParams_M1
extern void USER_setParams_priv(USER_Params *pUserParams);

    objUser->estWaitTime[EST_STATE_ERROR] = 0;
    objUser->estWaitTime[EST_STATE_IDLE] = 0;
    objUser->estWaitTime[EST_STATE_ROVERL] = (float32_t)(3.0 * USER_M1_ISR_FREQ_Hz);
    objUser->estWaitTime[EST_STATE_RS] = 0;
    objUser->estWaitTime[EST_STATE_RAMPUP] = (float32_t)((USER_MOTOR1_FLUX_EXC_FREQ_Hz /
            USER_M1_MAX_ACCEL_Hzps + (float32_t)1.0) * USER_M1_ISR_FREQ_Hz);

    objUser->estWaitTime[EST_STATE_CONSTSPEED] = (float32_t)(0.0 * USER_M1_ISR_FREQ_Hz);//0.0
    objUser->estWaitTime[EST_STATE_IDRATED] = (float32_t)(6.5 * USER_M1_ISR_FREQ_Hz); //10
    objUser->estWaitTime[EST_STATE_RATEDFLUX_OL] = (float32_t)(2.2 * USER_M1_ISR_FREQ_Hz);//1.0
    objUser->estWaitTime[EST_STATE_RATEDFLUX] = 0;
    objUser->estWaitTime[EST_STATE_RAMPDOWN] = (float32_t)(0.0 * USER_M1_ISR_FREQ_Hz);
    objUser->estWaitTime[EST_STATE_LOCKROTOR] = 0;
    objUser->estWaitTime[EST_STATE_LS] = 0;
    objUser->estWaitTime[EST_STATE_RR] = (float32_t)(5.0 * USER_M1_ISR_FREQ_Hz);//10
    objUser->estWaitTime[EST_STATE_MOTORIDENTIFIED] = 0;
    objUser->estWaitTime[EST_STATE_ONLINE] = 0;

    objUser->RsWaitTime[EST_RS_STATE_ERROR] = 0;
    objUser->RsWaitTime[EST_RS_STATE_IDLE] = 0;
    objUser->RsWaitTime[EST_RS_STATE_RAMPUP] = (float32_t)(3.2 * USER_M1_ISR_FREQ_Hz);
    objUser->RsWaitTime[EST_RS_STATE_COARSE] = (float32_t)(4.3 * USER_M1_ISR_FREQ_Hz);
    objUser->RsWaitTime[EST_RS_STATE_FINE] = (float32_t)(5.5 * USER_M1_ISR_FREQ_Hz);//10
    objUser->RsWaitTime[EST_RS_STATE_DONE] = 0;

#if defined(_FULL_FAST_LIB)
    objUser->RrWaitTime[EST_RR_STATE_ERROR] = 0;
    objUser->RrWaitTime[EST_RR_STATE_IDLE] = 0;
    objUser->RrWaitTime[EST_RR_STATE_RAMPUP] = (float32_t)(1.2 * USER_M1_ISR_FREQ_Hz);
    objUser->RrWaitTime[EST_RR_STATE_COARSE] = (float32_t)(1.3 * USER_M1_ISR_FREQ_Hz);
    objUser->RrWaitTime[EST_RR_STATE_FINE] = (float32_t)(1.4 * USER_M1_ISR_FREQ_Hz);
    objUser->RrWaitTime[EST_RR_STATE_DONE] = 0;
#endif // _FULL_FAST_LIB

    objUser->FluxWaitTime[EST_FLUX_STATE_ERROR] = 0;
    objUser->FluxWaitTime[EST_FLUX_STATE_IDLE] = 0;
    objUser->FluxWaitTime[EST_FLUX_STATE_CL1] = (float32_t)(1.0 * USER_M1_ISR_FREQ_Hz);
    objUser->FluxWaitTime[EST_FLUX_STATE_CL2] = (float32_t)(3.0 * USER_M1_ISR_FREQ_Hz);
    objUser->FluxWaitTime[EST_FLUX_STATE_FINE] = (float32_t)(4.0 * USER_M1_ISR_FREQ_Hz);
    objUser->FluxWaitTime[EST_FLUX_STATE_DONE] = 0;

    objUser->LsWaitTime[EST_LS_STATE_ERROR] = 0;
    objUser->LsWaitTime[EST_LS_STATE_IDLE] = 0;
    objUser->LsWaitTime[EST_LS_STATE_RAMPUP] = (float32_t)(4.20 * USER_M1_ISR_FREQ_Hz);
    objUser->LsWaitTime[EST_LS_STATE_COARSE] = (float32_t)(6.3 * USER_M1_ISR_FREQ_Hz);
    objUser->LsWaitTime[EST_LS_STATE_FINE] = (float32_t)(6.4 * USER_M1_ISR_FREQ_Hz);
    objUser->LsWaitTime[EST_LS_STATE_DONE] = 0;

C2000™︎ 微控制器（参考译文帖）

C2000™︎ 微控制器（参考译文帖）(Read Only)

[参考译文] LAUNCHXL-F280049C：UMCSDK v5.03编译错误&amp；MCSDK4.0电机 ID 符号从 LSRAM 中缺少运行代码