tag 标签: datasheet

相关帖子
相关博文
  • 热度 1
    2014-9-29 18:13
    1240 次阅读|
    0 个评论
    We are all familiar with saying "the devil is in the details". All too often those details are hidden deep within a datasheet where you can easily overlook them. When a datasheet reference circuit is copied into a product, the designer must still be fully aware of how the circuit functions and anticipate unexpected problems that might arise from slight deviations.   Take a recent case of an LT1640 hot-swap controller IC, often used in a hot-plug telecom fan tray. I was asked to reverse-engineer this so our technicians would know how to power it on the bench without a using a chassis. Nothing complicated about it, just the usual slow turn-on of a pass MOSFET in series with the load, thereby slowing the dV / dt and limiting the inrush current to the load input-filter capacitors.   After drawing some schematics, I connected it to my -48V power supply and a resistive-only load, hit it a few times with a grabber clip at -48V to emulate true metallic contact bounce, and saw the nasty little surprise shown in figure 1 .   Figure 1: What caused this negative-going glitch in a hot-swap circuit?   For a circuit whose main purpose is to prevent sudden surges upon power-up, this one failed miserably. Now what?   Well, maybe that's why the customer sent this unit in for repair. An inrush-current power-suckout on hot-insertion can cause a momentary voltage sag that results in an entire system reset. I could easily imagine how a technician plugged in this fan tray and the entire shelf came crashing down. There must be a problem with the fan tray, right?   Unfortunately, because we engineers are such experts in fault-fixing, our esteemed-and-mighty management does not require our customers to include such mundane details as actually describing the failure mode of whatever they send in for repair. So, we were forced to guess.   A close-up of the premature MOSFET turn-on is shown in Figure 2 . On power-up the series-pass MOSFET is conducting for 800 µs, plenty of time to wreak havoc on the rest of the system.   Figure 2: A MOSFET conducts for 800 µs (low-going part of blue trace). That's enough to cause a system reset.   It so happened that this card included an identical and totally isolated slow-start circuit for the usual redundant second -48V supply. It too failed in exactly the same way. Figure 3 shows the recommended slow-start circuit copied from the Linear Technology LT1640 Hot Swap Controller datasheet .   Figure 3: The hot-swap circuit published by Linear Technology in its LT1640 datasheet.   No discharge path On startup, after the undervoltage (UV) input is satisfied, capacitor C1 is slowly charged by a 45 µA current source from the LT1640. Any event that requires turning off the pass MOSFET Q1 causes the LT1640 GATE pin to discharge C1 and the MOSFET C GS with a 50 mA current sink. This is clearly explained in the data sheet electrical specifications.   The customer's unit included a small capacitor between the UV pin and V EE , as suggested in the datasheet.   Note that there is no discharge path for C1 other than the LT1640 gate current sink. When the fan tray is removed from the shelf, it loses V DD and the LT1640 can no longer sink current. With sufficient capacitance at V DD and C1 at 150 nF, this is not a problem. The LT1640 should discharge C1 in its last dying gasp (unfortunately, this aspect is not discussed in the datasheet). So, the original designer of the customer's product included only an EMI input filter with minimal capacitance.   To verify my failure mode assumption, I measured the Q1 gate-source voltage before and after power-up ( Figure 4 ), note the oscilloscope ground is now moved to the MOSFET source because I really hate trying to think in terms of negative voltages.   Figure 4: Because C1 doesn't discharge after initial power-up, it caused the glitch in Figure 1.   Just as I thought. After a first power-up, C1 and the MOSFET gate remain charged when the fan tray is unplugged from the shelf. So on the next power-up, C1 is still charged and the MOSFET remains conducting. C1 should have discharged.   That's exactly what the LT1640 is trying to do: discharge C1 at the new power-up, right?   But take a close look at the time—about 1.5 ms to discharge at 50 mA current sink. Seems kind of long for a 150 nF C1, doesn't it? Some back-of-the-napkin calculation (I = C dV/dt) indicates C1 seems more like 10 µF.   My bench DMM indicated that the customer's C1 was about 8.5 µF, measured in-circuit. I didn't trust that reading because the DMM measures C at 1 V and could be biasing some junctions on in the LT1640, giving a false reading. I mean, really, why would a design engineer stick a 10 µF capacitor where the datasheet reference circuit called for 0.15 µF?   Pulling out the heavy artillery, I drove the DUT C1 in-circuit through a 1K resistor with a ±400mV square wave from a function generator, a low enough voltage so as to not bias any silicon junctions in the LT1640, and displaying a convenient eight divisions peak-to-peak on the oscilloscope scale. With this trick, five divisions on the resulting risetime = 5/8 = 62.5%, close enough to the standard 63% RC time constant. The cursors mark 8 ms risetime to five divisions. Knowing the resistance, some more back-of-the-napkin calculation makes C1 about 8 µF, just as determined before.   Yes, the design engineer wanted a slower MOSFET turn-on time and had inserted a 10 µF, ±20% capacitor into a circuit that called for 0.15 µF, completely unaware of the problem it would cause. The data sheet didn't warn against this, nor did it warn of the possibility that the MOSFET gate could remain charged when the unit was unplugged from the system. With only a tiny leakage discharge current for C1, the MOSFET could remain in the conducting state for hours or days afterwards (kind of like DRAM), just waiting for another unsuspecting technician to hot-plug it into a system and bring it crashing down. With a capacitor this large, the designer should have included a bleeder resistor.   I'm really surprised that this design flaw wasn't discovered by the fan tray OEM during product testing prior to production release. My only theory is that their management laid off the contract designer as soon as the PCB was laid out and figured they didn't help to sort out any resulting bugs. Or maybe they just ignored the problem, hoping it would go away by itself.   Just for fun, I intend to try simulating this in LTspice. It will be interesting to see if this problem can be virtually reproduced.   Glen Chenier Engineer
  • 热度 3
    2014-6-18 17:58
    1027 次阅读|
    0 个评论
    Last year, I wrote a blog on the folly about using “typical” specs when designing systems . My sense is that a lot of feedback were from older engineers. As one of those myself, I have to confess that eons ago, as a freshly-minted EE, I was a rather careless designer. Need a pull-up? Any old resistor would do. Capacitors? Sure, select one based on voltage and capacitance. I rarely thought about tolerances, temperature effects, and the myriad other factors that make a circuit reliable in production. But sometimes there were problems, and I learned that between the lab and the manufacturing line lies a huge gulf. Fortunately, a mentor appeared, an older engineer who was a complete pain in the you-know-what. He critiqued everything. We had to justify the smallest design decisions. He’d demand small changes to meet his notion of getting things reliable. We all hated him.   But a strange thing happened. These carefully-reviewed designs worked. All the time. Customers weren’t ticked off. And it turns out that it’s actually interesting and rewarding to think through design decisions with care.   Another mentor appeared, a chemical engineer turned sailing bum. He taught me to apply the engineering method to building and maintaining ocean-going sailboats, where failures can be life-threatening. No fitting was too unimportant to think about from a stress, wear, and materials standpoint. Dan taught me to generalize the engineering mindset to life in general. Some politician makes an odd claim? Do the numbers. What’s likely to happen to the teenagers on that weekend at the beach? Do a worst-case analysis and develop contingency plans.   It drives my wife crazy.   In that article about typical specs I complained that the vendors spew “typical” numbers, but they admit that these aren’t tremendously useful for design. That thwarts any attempt to do careful engineering analysis when building a system. Consider this excerpt from an ARM datasheet:   My mentor of yore is rolling is rolling in his grave. This dearth of hard data makes it impossible to create a reliable design. As reader DaveSchabel replied in the comments to my earlier article “I'm not sure if the manufacturers realize that poor datasheets often eliminate an otherwise superior device from design-ins.” It wasn’t always this way. Here’s an example from TI’s 1976 TTL Databook for the 7447A BCD to seven segment decoder/driver:   Note that all of the specs have a max or min number, and the data shows what conditions those numbers apply to (e.g., Vol is with Vcc-MIN, Vih=2, Vil=0.8, Ioh=-200 uA). The typical specs aren’t much different from the worst-case numbers. Compare that to some MCUs whose max sleep current, in those rare cases where one is listed, might be two orders of magnitude greater than the listed typical. Admittedly, in the olden days just a few pages were enough to fully document a part. Today a thousand page spec isn’t uncommon, and that immense document commonly leaves out important information. Properly characterizing a component isn’t easy. Here’s another datasheet – it’s from a box of Entenmann’s donuts:   These are worst-case specs. They are guarantees. Contractual terms between Entenmann’s and the buyer. You know what you’re getting. Min/max specs, too, are guarantees. “Typical” is not. Why would one risk using a part that the vendor refuses to guarantee? Just last month an FAE from a large vendor told me some of their typical numbers are really marketing tools. Does that mean they can change with the competitive landscape? “Our competitor just dropped their typ specs; we better do the same!" Me, I want a guarantee. What’s your take?
  • 热度 4
    2012-10-21 16:45
    2413 次阅读|
    2 个评论
    今天才发现,TI官方已经发布了 中文 的数据手册(Datasheet),版本已经到了Rev.T 链接是官方文档的链接,可直接点击打开 http://www.ti.com.cn/cn/lit/ds/symlink/tms320f2812.pdf   或参考下面的附件,包括中文和英文   除了2812外,好像其他型号的也有了中文文档
  • 热度 44
    2011-9-9 17:28
    6066 次阅读|
    41 个评论
    并不是每家公司编撰产品数据的理念都是一样,有的倾向于技术保守;有些则攻击性强一些,在技术指标陈述上也更“大胆”一点。看懂产品数据对用户来说并不容易,本文通过几个小例子,介绍一些小细节,帮助大家去看清楚这种资料。   说实话,看三家公司的示波器产品数据,不得不承认:我们公司的产品数据真是写得不太好,相比起来其它公司的资料是图文并茂,火力十足:把自己如何好,别人如何差描述得淋漓尽致!   但是必须要说的是,用户看到的指标只是这些公司想表达的,实际上是什么样的东西,却并不一定是用户“看到”的:   第一:保证值还是典型值? 以某个厂商的datasheet为例,从技术背景写到产品优势,从内部结构画到竞争图表,它的很多指标都是业界首屈一指的,给用户的视觉冲击力确实很强。但仔细看看它的datasheet,请注意,只有标“*”的才是保证值,其它均为典型值。你猜它保证多少个指标?应该很多吧?!残酷的现实是:只有寥寥四个。他们引以为傲的噪声、抖动噪底、通道隔离度等等等等,全是典型值——典型值的话,用户你自己达不到就不要怪我咯,因为你的测试条件不“典型”啊。反观泰克的产品数据,datasheet中的“典型值”全部标出“typical/典型值”,未标示的全是保证值——“保守”,这是我看我们产品数据的最大感觉。    第二,小心偷梁换柱——看似相似的指标,其实有很大不同  有些指标,如果别人比较好,我可以做些解释,但会承认别人的优势。但我自将心对明月,无奈明月……举个例子,泰克有个对于调试很好的工具,叫快采功能,也叫DPO功能,其核心指标是波形捕获率,也就是说每秒钟捕获的波形个数。还有一个功能是内存分段模式,其它公司也叫序列模式。这种内存分段模式的核心指标是连续触发速率。泰克在产品数据中明确地给出了这两个指标。当然,由于DPO功能是泰克的独有功能,所以在“波形捕获率”上肯定是首屈一指的。其它公司为了弱化泰克这一优势,直接将其“连续触发速率”和泰克的“波形捕获率”做比较,完全忽视了其实这是两个不同的指标,而且泰克也有“连续触发速率”指标——无论你泰克有没有,我反正直接无视。如果用户不仔细看的话(其实这点对用户来说很难),一个非常好的调试优势就不见了——当然这要拜竞争对手所赐。   另一个例子是某厂商的触发抖动指标——其实他们的高性能示波器根本没有这个指标,只有“显示抖动(显示触发抖动)”指标,这不是真正意义的“触发抖动”。从示波器原理来说,触发抖动是肯定存在的,它是硬件上的东西。但是各家都会使用一些软件优化的方法来减小触发抖动。所以其他示波器厂商都会标出两个相关数据:硬件触发抖动和软件优化后的触发抖动。触发抖动指标上,比如泰克写得很清楚,硬件的触发抖动1ps,经过软件优化后小于100fs。而他们的“显示抖动”的指标是50fs。你猜他们是怎么对比的?它用50fs对泰克的1ps——多么令人崩溃的比较啊:他们明明也是软件优化的,它连软件优化都关不掉!泰克就是因为能关掉,结果被人这么比。怎么知道他们的是软件优化的呢?其实很简单:一个上升时间较快的信号功分两路,分别进两个通道(如通道1和3),触发通道定为1,观察通道3信号在触发位置的抖动即可——两个信号既是同源的,就应该完全重合,如果重合不了,则证明有一个信号被处理过——你会认为哪一个是被处理过呢?   第三:小心datasheet中的注释 注释无外乎几种功能,一种是确实需要较大篇幅的解释,为了不影响阅读的连贯性,另找地方专门解释;另一种是写在这里“不好看”,不如用注释的方式告知真相,所以其实注释是大有看头的。   比如某厂商的datasheet就有很多指标有注释标志,然后在很远很远的地方用小得几乎看不见的告诉你真相,如果你忽略了,那就是你活该。   举个例子,业界最牛的垂直刻度指标(2011年4月版):垂直灵敏度 1mV~1V/div,旁边标了个注释2。那注释2是怎么写的呢? 2. Full scale is defined as 8 vertical divisions. Magnification is used below 10mV/div. Below 10 mV/div, full-scale is defined as 80 mV/div. The major scale settings are 5mV, 10mV, 20mV, 50mV, 100mV, 200mV, 500mV, and 1V. 看不清楚吧,为了体现看datasheet的痛苦,我保留了原文的字体和大小。这个注释什么意思呢?实际上10mV/div以下不是硬件实现的,而是视觉放大的。也即是说,硬件灵敏度是10mV起的——这就和表面看起来的1mV起差远了。能把视觉(软件)放大的东西放在“灵敏度”指标里,这也算该公司的一个创举吧。   这个指标还有个暗示:该示波器实际上只使用几个major scale,其它的刻度是如何实现的呢?我就不知道了……   第四,注意产品指标的变化(虽然这点用户很难做到) 有些示波器的指标是可以“随机应变”,以下是某厂商DSOX90000系列示波器几个关键指标的变化,同一个型号的仪器会这样频繁地变化,是在不断“改进”,还是仅仅是在不断“改动”? 可以看到,他们的几个技术指标总是在变化。有一些是出现了消失,消失了又出现,如采样时钟抖动,而且越变越差。像他们一直强调的通道隔离度,之前也不是那么“优异”的,偏置范围后来几版又改小了(为什么?);而硬件灵敏度在泰克推出6.25mV/div后立刻就改成了7.5mV/div,早干嘛去了,是不是有什么难言之隐,居然在这一档上没有标出其一直骄傲的“噪声”指标;还有带宽,十分有趣,示波器历史上也只有他们的示波器带宽标示过“典型值”。     小结: 产品数据本来应该是很严谨的东西,但是当前较为激励的竞争环境下,厂商在产品数据上做点动作也是可以理解的。行业内人士对这些动作当然了如指掌,但是不太熟悉情况的用户看起来就有点费劲了。本文用几个小例子,给用户一些看数据的建议,个人意见仅供参考。
  • 热度 4
    2009-1-21 09:10
    2043 次阅读|
    2 个评论
    走进嵌入式研发 2004 年年初,我下定决心离开了让我饱受贫穷困扰的 A 公司。 F 君将欠我的工资分两次补齐之后,我开始小小的富裕起来。我用这笔钱和焱的一些积蓄为我们的小家添置了电冰箱、电视机、洗衣机等生活用品,还去钟爱一生照了一套婚纱照。焱也在婚后从东莞跳槽到了深圳。我们的小日子开始过得像模像样起来。 我又开始奔波于深圳市人才市场,寻求一份适合自己的工作。由于有了半年的开发工作经验,加上对电子产品的生产流程较为熟悉,这次找工作,开始容易了许多。面试了好几家公司后,我选中了 B 公司,职务是工程部的电子工程师。 B 公司是一家港资集团下的子公司,主要生产可视电话。在当时, VoIP 的发展还很一般,可视电话也算是一件高技术含量的家用电器了。 刚进公司的第一个星期,工程部的头头给了我公司产品的 BOM 表、电路板、电路图等资料让我研究。第一次接触嵌入式系统的开发,望着那一片片集成电路芯片,我开始一头雾水,不知该从哪儿开始。发了一天的呆后,我决定先研究下电路板上的每一块 IC 的用途。 上班的第二天,我将 IC 的型号抄在笔记本上,拿着去向其他工程师讨教每个芯片的用途,哪个是网卡,哪个是 Modem ,哪个是处理器,那个是 Flash 等等,然后回来一一背熟悉。接下来,我对着电路板,记忆每个功能模块的布局。然后开始拿电路图研究每个功能模块的电路,可是看着每个芯片有那么多的引脚,除了电源和地,我也不知道每个引脚的功能,以及引脚外面走的电路的意义。我带着这个疑问又去向其他工程师讨教,人家只是说:“我也不清楚,你要看这个芯片的 Datasheet 和参考设计。” “ Datasheet 是什么?哪儿有啊?” “芯片参数说明书呗,你可以自己上网搜索下。” “怎么搜啊?”我还是不太明白,毕竟第一次接触集成电路的设计,这可和我以前做的衣车节电器相差甚远。 “晕!你以前不是还做过研发吗?怎么搜芯片资料都不知道?” “我以前没有做过和芯片有关的电路开发,只是做强电类的……”,我羞得满脸通红。 “那 Google 总会用的吧,你输入芯片的型号进去,自己找找看不就知道了。” “哦!谢谢啦!”我赶紧跑回自己的座位,不敢再问太多让他们觉得很弱智的问题了。 经历了这一次之后,我在 A 公司培养起来的张扬的自信受到了较大的打击,好强好胜的心理驱使我不愿意再去多问人家问题。打这以后, Google 成了伴随我研发职业生涯的最好的良师。 第一次接触 Datasheet ,我非常不习惯,因为所有芯片的 Datasheet 都是英文的,很多内容我都看不懂,只好傻傻的拿金山词霸一个一个的翻译,遇到常见的生词,还认真的拿个笔记本记下来,回家背诵。 这样糊里糊涂的看了快一个星期的资料。这一天,工程部的头头突然走过来对我说:“你收拾收拾自己的办公用品,去研发一室 J 工那里报道吧!” “为什么去那里上班?” “以后你就在硬件研发部门工作了,你过去了, J 工会给你介绍具体情况的。” 我满腹狐疑的开始收拾东西了,在我搬东西去研发部的同时,研发部的两名员工也正搬东西往工程部这边来。说是他们两个换我过去。我更加不解了。我明白,研发部的工作难度要比工程部的大很多,我自认为连工程部的工作都很难胜任,为什么会突然调我去研发部呢?难道我最近认真地态度得到领导的赏识了?也不对啊,那个 J 工根本都不了解我现在在做什么啊! 搬到研发一室, J 工热情的招待了我,并解释说,因为工程部最近很忙,研发部很闲,所以他们贡献出了两名研发人员去工程部工作,让我过研发部这边来学习和工作。 原来是这样,那可真是天上掉下馅饼了啊!可以当一名研发工程师,可是我梦寐以求的事情呢!做研发,多派啊!可以学到好多东西呢!待遇也高很多。我望着这个曾经在人事部碰见过一次的 J 工,望着他笑盈盈的脸,感激之情油然而生——不是伯乐胜似伯乐! 就这样,我的硬件研发生涯正式开始了,一切顺利得出乎意料。
相关资源
广告