TMS320F2802x Errata汇总(ADC部分)

简单汇总一下TMS320F2802x的Errata情况:

本文基于Errata版本:http://www.ti.com/lit/er/sprz292j/sprz292j.pdf

1. ADC:初始化转换(ADC: Initial Conversion)

影响版本:0

问题描述:当ADC转换初始化的时候,被触发的一系列转换中,第一个转换结果不正确。

解决方法:在ADCCLK为60MHz或40MHz时,抛弃第一个转换结果;或者在版本A中,将ADCCTL2中的ADCNONOVERLAP和CLKDIV2EN置1,使得ADC转换时钟将为30MHz。

评论:在ADC中,要么丢弃每个转换序列中第一次转换结果,要么降低ADC时钟速度。

2. ADC:温度传感器最小采样窗口的需求(ADC: Temperature Sensor Minimum Sample Window Requirement)

影响版本:0,A

问题描述:当温度传感器采样选择最小的采样窗口时(6ADC时钟@60MHz,116.67ns),温度传感器转换结果与实际值有较大的误差。

解决方法:1). 采用双采样的方法——连续进行两次采样,丢弃第一次转换的结果,使用第二次转换结果。这样等效于给了采样保持器(S/H)足够的时间进行采样。2). 配置采样保持器(S/H)的窗口时间超过550ns。

评论:温度转换的时候需要较长的采样时间。

3. ADC:直流特性:线性度限制(ADC: DC Specifications: Linearity Limitation)

影响版本:0,A

问题描述:在上半部分的传递函数中,线性度随着温度的升高而下降。

解决方法:1). 将ADC时钟通过CLKDIV2EN设置为1,在60MHz的时钟下,采样速率降低为2.3MSPS,这样得到了30MHz ADC时钟和60MHz系统时钟,可以解决线性度问题。2). 现有的流水线模式可以工作在4.6MSPS@60MHz系统时钟,可以提升线性度。

评论:仍然是采样速率过快导致的ADC采样精度缺失

4. ADC:新的ADC控制位在A版中被添加进来(ADC: New ADC Control Bits Added to Revision A Silicon)

影响版本:A

问题描述:添加了新的控制位ADCCTL2@0×7101,包含CLKDIV2EN,可以使ADC时钟降低为系统时钟的1/2;ADCNONOVERLAP一个使能位,可以用来关闭采样/转换过程的重叠时间。

解决方法:无

评论:添加了新控制位用来改善糟糕的ADC性能

5. ADC:上电后不符合特性的电流消耗(ADC: Out-of-Specification Current Consumption on Power Up)

影响版本:0,A

问题描述:当系统的ADC模块首次上电后,会消耗双倍于数据手册中标明的电流(Idda),该问题持续到第一次AD转换后消失。

解决方法:在ADC初始化之后立即产生一次假的AD转换,随后电流消耗会恢复到数据手册所规定的电流。如果这段时间的电流消耗是可以接受的,则无需进行任何更改。参考代码如下:

EALLOW;

SysCtrlRegs.PCLKCR0.bit.ADCENCLK=1; //Enable Clocks to ADC module

AdcRegs.ADCSOCFRC1.bit.SOC0 = 1; //Issue dummy conversion

asm(” rpt #19 || nop”); //Wait for conversion to propagate

AdcRegs.SOCPRICTL.bit.SOCPRIORITY = 1; //Change Priority Control to reset

AdcRegs.SOCPRICTL.bit.SOCPRIORITY = 0; //round robin pointer

EDIS;

评论:如果初始化以后没有进行转换,会一直消耗较多的电流,否则可以忽略这个问题

6. ADC: ACQPS=6 or 7时,前一次转换结果之后的14个周期的ADC结果转换(ADC: ADC Result Conversion When Sampling Ends on 14th Cycle of Previous Conversion, ACQPS = 6 or 7)

影响版本:0,A

问题描述:片内的ADC在采样阶段结束后,用13个ADC时钟周期来完成转换。随后,采样后的第14个周期会被提交给CPU,第15个周期被锁存在ADC结果寄存器中。如果下一次转换的采样阶段在前一次的第14个周期结束,CPU在结果寄存器中锁存的结果不能保证在所有条件下都是有效的。

解决方法:有几种方法可以解决这个问题。1). 由于产生问题的是ADC的采样和转换阶段,只有两个ACQPS的值会出现这个问题:6或者7,因此尽量避免使用这两个值。2). 将ADCNONOVERLAP的值(ADCCTL2的bit 1)设置为1,不会再遇到任何问题,此时可以使用任意的ACQPS的值。3). 根据系统中ADC采样的频率,用户可以判断使用ACQPS = 6或者7是否会触发这个情况;如果转换持续工作在ACQPS = 6的状态,上面的情况不会发生,因为采样结束的时候出现在当前转换的第13个周期。

评论:避免在转换的第14个周期结束采样,本来可以充分利用流水线加快采样速率。

以上是Errata涉及到的ADC的部分问题。

更新服务器

最近更新了服务器,整体构架由原来的LAMP变为LNMP,其中的Apache变为Nginx。系统资源消耗更少,但是配置起来不是很得心应手。

由于变更了服务器地址,响应速度可能会有些影响。

我的浮点心 – CLA简介(上)

在TI的产品线中,F2803x Piccolo™系列处理器主打低成本高效控制的路线。在数据计算部分,虽然有IQMath这个伪浮点数计算库,但是在平均最高60MHz的处理速度下,仍然后很多工作无法胜任。为了提高性价比,TI在其中引入了一个新的概念:控制率加速器(Control Law Accelerator, 简称CLA),主要功能是:在原有的CPU构架外,新增一个支持浮点运算的并行处理核心,实现“双核”控制。

什么时候需要用CLA?
1. 有大量的浮点数学运算,CPU在计算之余,还需要去响应各种外设的请求。
由于CLA是与原有的CPU并行进行计算,因此在原有的CPU中只需要设置好交换的数据并使能对应的CLA任务,CPU就可以去运行其它的任务,CLA运行完毕后会自动将规定好的数据传回。就好象对自己的助手说:“嘿,张三,帮我把这个表格按照公司的格式生成统计结果”,张三做完后会把数据送回来,而这段时间里你可以继续做其它的事情。
2. 采用IQMath库的时候,无法同时满足“精度”和“范围”的需求。
在IQMath库中,CPU将浮点运算转换成定点运算,因此有时无法在精度和范围两方面灵活互补,而CLA采用了浮点数,系统会自动对计算的精度和范围进行调整,达到最优的效果。
3. 程序需要对运行速度进行深度优化。
CLA运行的程序只能使用对应的汇编语言进行编程,用户可以在程序执行的流水线等待阶段插入不影响结果的语句,充分利用强大的计算能力,榨干处理器的每一点计算能力。

什么时候不适合使用CLA?
1. 有大量的判断、跳转语句(if…else… for… while…)需要运行。
由于CLA采用8级流水线结构,数据的计算能力非常强大,但是在判断和跳转语句中会造成后续的流水线失败,因此,大量的判断和跳转操作最好放在CPU中进行。
2. 需要访问复杂的外设。
CLA虽然和CPU共用大多数资源,但是前者只能访问PWM和ADC的有限的寄存器,其它的寄存器访问需要间接的向CPU请求,由此也可以看出来,CLA的存在,主要是为了强化基于PWM控制的运算,而CPU可以更轻松的控制丰富的外设。

CLA的有什么不足?
1. 与CPU共用内存资源
CLA没有自己的内存资源,因此必须从CPU中划分出对应的内存区域供CLA的程序和数据使用。
2. 没有只有乘法器和加法器
CLA只有乘法器和加法器,没有硬件除法器,因此除法运算需要的周期还是远大于乘法。

以上是关于选用CLA使用的一些简介。

Android的同步

用了HTC Desire一年了,一直刷的官方的ROM,最近尝试一下基于CM Mod的MIUI版ROM,发现明显比港行官方ROM修改出来的版本要省电,功能也更平易近人一些。

可是发生了一个悲剧的事件:无法与Outlook同步联系人!

因为工作原因,平时使用的邮件客户端是Outlook。以前是HTC的ROM,通过HTC Sync可以与Outlook双向同步联系人;但是MIUI里面并没有HTC Sync的功能,因此再也无法更新联系人,导致很多联系人发生了改变之后只能通过手工两边修改成同样的内容,随着时间,这项工作越来越繁重,生怕两边有些许不同。

之所以买手机之后没有立即使用Google账户来同步联系人,是因为Gmail已经使用了很久,列表中的联系人嫉妒杂乱无章,属于各种随意使用之后的后遗症。

后来忍无可忍,先清理了一下Gmail联系人列表,然后把Outlook导出到Google Contact中去。然后开启了Google Contacts的同步,基本上实现了联系人的“云端”存储

28035内部温度传感器的使用

在TMS320F28035的Analog-to-Digital Convert (ADC)模块中,内置了一个温度传感器,在进行ADC的时候可以设置ADCINA5通道为内部温度传感器,并且对其进行采样。

1. 需要将设置ADCCTL1[Bit0:TEMPCONV]设置为1,以开启内部的温度传感器。
2. 根据说明,读取出厂预标定值,包括斜率(slope)和偏移(offset)。
0x3D7E82 – Slope (ºC / LSB, fixed-point Q15 format)
0x3D7E85 – Offset (0 ºC LSB value)
3. 设置转换。
以最快转换速度进行转换(ACQPS = 6; // 7 ADC Clock @ 60MHz):需要连续两次转换,并且读取后一次的值为准;
以超过550ns的速度进行转换(ACQPS >= 32; // 33 ADC Clock @ 60MHz ),可只读取一次。
4. 以公式进行转换
Temperature = (sensor – Offset) * Slop
5. 你会发现转换后的值不对。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

经试验,在室温20摄氏度的时候,采集到的值约为2190,slope 约等于 0.217,offset 为1750,计算得到的值为126摄氏度。
使用Fluke561红外温度监测仪进行扫描,CPU外壳部分温度约为30~34摄氏度,与计算得到的值相差较大。
将计算得到的温度值:126作为华氏度转换为摄氏度后,温度约为52.2摄氏度。考虑到温度传感器所采集的位置为结温,会高于外壳温度,因此,得出结论:
TMS320F28035处理器的ADC模块内部温度传感器所采到的值应该是华氏度,而不是摄氏度。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
华氏度 – 摄氏度转换公式:

华氏度=32+摄氏度×1.8
摄氏度=(华氏度-32)÷1.8

相关文档:
TMS320x2802x, 2803x Piccolo Analog-to-Digital
Converter (ADC) and Comparator Reference Guide

TMS320F2803x Piccolo MCU Silicon Errata
TMS320x2802x, 2803x Piccolo Datasheet

I2C模块的从机接收

今日在使用TMS320F28035的时候用到了I2C模块,两个同样的处理器通过I2C总线进行通讯。

在使用的过程中,”主->从”方向的通讯没有问题,但是在“请求 – 响应”的双向通讯中,总是出现问题。

具体表现为:

主机发送的 7-bit 从机地址之后的R/W位总是保持写入的状态(0),导致从机无法正常响应通讯的数据,总线保持繁忙状态。

程序参考了:2803x C/C++ Header Files and Peripheral Examples sprc892.zip

以及:PMBus sprabj6-Software Implementation of PMBus Over I2C.pdf

 

GPIO用做输入的问题

今天在使用TMS320F28035这款MCU的时候,出现了一个问题:

被用做输入的端口无法真实反映出外部的高低电平状态。

排除了外部的因素后,发现GPIO用做输入的时候,MCU内部的上拉电路仍然在起作用,并且影响着输入信号的电平状态。

解决方法:

由于GPIO端口(除了可以用作ePWM的端口)默认开启了内部上拉功能,因此:

用做输入端口时一定要关闭对应管脚内部的上拉功能

涉及到的寄存器为:GPAPUD / GPBPUD

28035之时钟选择

TMS320F28035这款DSP(现在应该是MCU了)具有2个片内时钟振荡器,同时具有1个晶振输入和1个外部时钟输入。

INTOSC1:片内时钟振荡器1(10MHz),可以为看门狗、系统内核、CPU定时器2提供时钟基准。

INTOSC2:片内时钟振荡器2(10MHz),可以为看门狗、系统内核、CPU定时器2提供时钟基准。

Crystal / Resonator:采用外部晶振作为时钟基准(XTAL),硬件上连接在X1 / X2脚。

External Clock Source:外部时钟源(XCLK – GPIO19 / GPIO38),如果没有使用外部晶振,那么可以使用一个外部的时钟源接入到XCLKIN管脚上,提供时钟基准。

默认情况下,系统内核时钟是由INTOSC1提供的,经过实际使用下来,片内的INTOSC1INTOSC2并不是很精确,并且受温度影响较大。如果使用外部晶振,应该如何切换呢?

1. 启用编辑受保护的寄存器;

1
EALLOW;

2. 将CLKCTL[XTALOSCOFF]设置为0,启用外部晶振;并将CLKCTL[XCLKINOFF]设置为1,禁用外部时钟输入;
参考操作:

2
SysCtrlRegs.CLKCTL.all = 0x2400;

3. 将CLKCTL[OSCCLKSRCSEL] 设置为1,使用外部晶振作为系统时钟源;此时,系统时钟无分频和倍频,需要重新设置PLLCR;
参考操作:

3
SysCtrlRegs.CLKCTL.all = 0x2401;

4. 重新设置PLLCR,并等待设置完毕;
参考操作:

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 1)
{
    SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;
    SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;
    SysCtrlRegs.PLLCR.bit.DIV = 0x000C;
    while(SysCtrlRegs.PLLSTS.bit.PLLLOCKS != 1)
    {
        SysCtrlRegs.WDKEY = 0x0055;
        SysCtrlRegs.WDKEY = 0x00AA;
    }
    SysCtrlRegs.PLLSTS.bit.MCLKOFF = 0;
    DelayUs(20/2);
    SysCtrlRegs.PLLSTS.bit.DIVSEL = 0x2;
}
else
{
    asm(" ESTOP0");
}

5. 关闭内部晶振INTOSC1;
参考操作:

22
SysCtrlRegs.CLKCTL.all = 0x2501;

6. 禁止编辑受保护的寄存器;

23
EDIS;

这样DSP可以工作在一个相对稳定和精确地时钟基准下。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
参考文档:
P43 – TMS320x2803x Piccolo System Control and Interrupts Reference Guide (Rev. B)
From Ti.com

关于DSP供电GND的问题

今天在调试DSP的时候连续烧毁了3块2812,都很诡异,很无奈,很纠结。

鼓起勇气再试一次的时候,终于发现了问题所在:

每次在CCS连接仿真器的时候,+5V供电的电流就会突然升高,DSP的内核部分+1.8V和外设部分+3.3V的阻值<50Ω。初步认为是+5VGnd对保护地的压差>54V,连接仿真器的瞬间产生一个很大的冲击,将DSP内核烧掉。

问题待解决