[参考译文] TMS320F28035：TMS320F28035

从何处可以看到 AdcConversion()只能从 RAM 中工作？ 通常、从 RAM 运行函数是为了提高速度或使执行周期数更具确定性而做出的决定、因为闪存可能具有等待状态、缓存、预取等...例如、 DELAY_US()的底层函数从 RAM 运行，以便每个循环的周期数最精确。 我们还从 RAM 运行 InitFlash、因为在配置闪存设置时、不应尝试从闪存执行。

当然、CLA 代码是例外的、它只能从 RAM 中执行。

一种快速找到我们建议您从 RAM 运行的 controlSUITE 中 F2803x 器件支持文件夹中的所有函数的方法是快速搜索"ramfuncs"-该目录应查找用于将函数放入 RAM 的所有#pragma CODE_SECTION 行。

惠特尼

尊敬的惠特尼

感谢您的支持。   我正在开发一个基于 TM320F28035的新项目。  我开始使用实验套件、并尝试从闪存执行 ADC 示例、但它不起作用。  我在论坛上发布了从 RAM 运行 AdcConversion()的建议(请参阅下面的链接)。  示例仅在从 RAM 运行 AdcConversion()后有效。

" ">e2e.ti.com/.../4160220

不确定如何在文件中搜索 ramfuncs。

此致、

Ramesh

Ramesh、

明白。 我将与 Matt 交谈、看看我们是否需要提交错误以将#pragma CODE_SECTION 添加到代码中、从而避免将来出现这种混淆。

[引用 userid="318028" URL"~/support/microcontrollers/C2000-microcontrollers-group/C2000/f/C2000-microcontrollers-forum/1122556/tms320f28035-tms320f28035/4163939#416393939"]不确定如何在文件内搜索 ramfuncs。

许多代码编辑应用程序(如 Visual Studio Code 等)都有文件搜索选项。 即使 CCS 也有搜索选项(View -> Other...、Find Search)。 其外观如下所示：

惠特尼

尊敬的惠特尼：

非常感谢。  还有一个问题-为什么我们应该从 RAM 中运行 AdcConversion()？  是因为以下几行

while (AdcRegs.ADCSOCFLG1.bit.SOC9 ==1)
｛

｝

可以确认吗？

此致、

Ramesh

我无法重现此问题、因此无法观察到确切的行为、但我可以看到它可能对时间敏感。 我猜的是、由于中断不是处于连续模式、如果中断未在特定窗口内清除、则可能会设置中断溢出标志(您可以检查 ADCINTOVF 寄存器以查看是否看起来是这样)。

惠特尼

我检查  了 ADCINTOVF 寄存器，它读作：0x0002 ，表示溢出标志被置位。  此外、我注意 到程序计数器在以下地址之间循环- 3f61D9、 3f61DC、 3f61DD。  您看到了这方面的任何线索吗？

此致、

Ramesh

这些地址看起来像引导 ROM 地址。 您似乎正在获得某种类型的复位、或者可能是意外中断、该中断会将您发送到引导 ROM 的默认 ISR。 您可以尝试加载 ROM 符号以查看它是什么函数。 它们位于：

\libraries\boot_rom\f2803x\v1_0\rom_sources\Release\TMS320x2803x_boot_rom_Gold_V1.out

惠特尼

我检查了.map 文件、它似乎是执行用户代码的闪存 RAM。  此特定地址位于 AdcConversion()函数内。

页地址名称
------ ----
0 00008000 _DSP28x_usDelay
0 00008000 _RamfuncsRunStart
0 003f0000 _RamfuncsLoadStart
0 003f6000 .text
0 003f6000 _InitAdc
0 003f6000 __text__
0 003f601f _InitAdcAio
0 003f6041 _AdcOffsetSelfCal
0 003f6068 _AdcChanSelect
0 003f60dd _AdcConversion
0 003f622e _INT13_ISR

很抱歉--你是对的。 引导 ROM 从0x3FE000开始。 0x3F6xxx 是有效的闪存地址。 您无法分辨这些3f61D9、 3f61DC、 3f61DD 地址在 C 代码中对应的行是什么？ 反汇编代码是什么样子的？

惠特尼

如何检查拆卸？

此致、

Ramesh

我可以生成.lst 文件。  我的观察是、它停留在以下几行中

while (AdcRegs.ADCINTFlG.bit.ADCINT2 ==0)
｛

｝

ADCINTFLG 被读取为00。

映射文件的一部分

页地址名称
------ ----
0 00008000 _DSP28x_usDelay
0 00008000 _RamfuncsRunStart
0 003f0000 _RamfuncsLoadStart
0 003f6000 .text
0 003f6000 _InitAdc
0 003f6000 __text__
0 003f601f _InitAdcAio
0 003f6041 _AdcOffsetSelfCal
0 003f6068 _AdcChanSelect
0 003f60dd _AdcConversion
0 003f622e _INT13_ISR
0 003f6233 _INT14_ISR
0 003f6238 _datalog_isr
0 003f623d _RTOSINT_ISR

   下面 DSP2803x_adc.c 的.lst 部分

800 .dwpsn 文件"C：/ti/C2000Ware_4_01_00_00/device_support/F2803x/common/source/DSP2803x_adc.c"、第333行
801 000001d4 761F！ MOVW DP，#_AdcResult+7；[CPU_ARAU]
000001d5 0000
802 000001d6 0E07！ MOVU ACC、@$blocked (_AdcResult)+7；[CPU_ALU]|333|
803 000001d7 0742附加 ACC，*-SP[2]；[CPU_ALU]|333|
804 000001d8 1E42 MOVL *-SP[2]、ACC；[CPU_ALU]|333|
805 .dwpsn 文件"C：/ti/C2000Ware_4_01_00_00/device_support/F2803x/common/source/DSP2803x_adc.c"、第338行
806 000001d9 $C$L3：
807 .dwpsn 文件"C：/ti/C2000Ware_4_01_00_00/device_support/F2803x/common/source/DSP2803x_adc.c"、第338行
808 000001d9 761F！ MOVW DP、#_AdcRegs+4；[CPU_ARAU]
000001da 0000
809 000001db 4104！ TBIT @$blocked (_AdcRegs)+4、#1；[CPU_ALU]|338|
810 000001dc 6CFD B $C$L3、NTC；[CPU_ALU]|338|
811；出现 branchcc；[]|338|
812 .dwpsn 文件"C：/ti/C2000Ware_4_01_00_00/device_support/F2803x/common/source/DSP2803x_adc.c"、第343行
813 000001dd 1A05！ 或@$blocked (_AdcRegs)+5、#0x0002；[CPU_ALU]|343|

此致、

Ramesh

我是指调试器反汇编窗口--在 Debug 透视图中转到 View -> Disassembly 将其打开。 不过、您的下一篇文章确实回答了我的问题。

当 ADC 中断不在连续模式中时、在 ADCINTFLG 被清零前不会再产生中断脉冲。 而是设置 ADCINTOVF 标志。 因此、我怀疑 ADCINTFLG 在下一个要置位的 EOC 事件中没有及时清零、因此它将收到 ADCINTOVF 事件、并且不会生成中断脉冲来启动下一轮转换。 尽管 ADCINTFLG 最终被清零、但它发生得太晚了。

我不确定启用连续模式是否可以解决问题、但您可以尝试一下。

惠特尼