标签: watchdog

说明： 网上能搜到的硬件工程师笔试面试的题库虽然也有一些，但是有些题目太旧，也没有更新，有的答案有错误，对初入行的工程师反而有误导。因此，并产生了此题库。 此题库精选网上能搜到的绝大多数硬件工程师笔试面试题库，部分由网友提供。题库大多数提供了参考答案，供应届毕业生以及要跳槽的工程师刷题，以及学习用。此题库经过刷选，尽量挑选有价值的笔试面试题目，供大家参考。 如果各位有好的题库，也可以留言，私信提供，后续一起编排进来，方便硬件 工程师刷题用 。 1、请解释WatchDog（看门狗）的工作原理。 看门狗有两个重要信号：时钟输入和复位输出。电路工作时，CPU 送出时钟信号给看门狗，即喂狗。如果系统出现故障， CPU 无法送出连续的时钟信号，看门狗即输出复位信号给CPU，复位系统。 2、请列举三种典型的ESD 模型。 人体模型（HBM）、机器模型（MM）、带电器件模型（CDM）。 3、请问RoHS 指令限制在电子电气设备中使用哪六种有害物质？ 限制使用铅、汞、镉、六价铬、多溴联苯（PBB）和多溴二苯醚（PBDE）等六种有害物质。 4、晶体管基本放大电路有共射、共集、共基三种接法，请简述这三种基本放大电路的特点。 共射：共射放大电路具有放大电流和电压的作用，输入电阻大小居中，输出电阻较大，频带较窄，适用于一般放大。 共集：共集放大电路只有电流放大作用，输入电阻高，输出电阻低，具有电压跟随的特点，常做多级放大电路的输入级和 输出级。 共基：共基电路只有电压放大作用，输入电阻小，输出电阻和电压放大倍数与共射电路相当，高频特性好，适用于宽频带 放大电路。 5、多级放大电路的级间耦合方式有哪几种？哪种耦合方式的电路零点偏移最严重？哪种耦合方式可以实现阻抗变换？ 有三种耦合方式：直接耦合、阻容耦合、变压器耦合。直接耦合的电路零点漂移最严重，变压器耦合的电路可以实现阻抗 变换。 6、名词解释：耦合、去耦、旁路、滤波。 耦合：两个本来分开的电路之间或一个电路的两个本来相互分开的部分之间的交链。可使能量从一个电路传送到另一个电 路，或由电路的一个部分传送到另一部分。 去耦：阻止从一电路交换或反馈能量到另一电路，防止发生不可预测的反馈，影响下一级放大器或其它电路正常 工作。 旁路：将混有高频信号和低频信号的信号中的高频成分通过电子元器件（通常是电容）过滤掉，只允许低频信号 输入到下一级，而不需要高频信号进入。 滤波：滤波是将信号中特定波段频率滤除的操作，是抑制和防止干扰的一项重要措施。 7、什么是竞争与冒险？ 逻辑电路中，由于门的输入信号经过不同的延时，到达门的时间不一致，这种情况叫竞争。由于竞争而导致输出产生毛刺 （瞬间错误），这一现象叫冒险。 8、无源滤波器和有源滤波器有什么区别？ 无源滤波器由无源器件 R、L、C 组成，将其设计为某频率下极低阻抗，对相应频率谐波电流进行分流，其行为模式为提 供被动式谐波电流旁路通道。无源滤波器可分为两大类：调谐滤波器和高通滤波器。无源滤波器结构简单、成本低廉、运行可 靠性高，是应用广泛的被动式谐波治理方案。 有源滤波器由有源器件（如集成运放）和 R、C 组成，不用电感 L、体积小、重量轻。有源滤波器实际上是一种具有特定 频率响应的放大器。集成运放的开环电压增益和输入阻抗很高，输出电阻很小，构成有源滤波电路后有一定的电压放大和缓冲 作用。集成运放带宽有限，所以有源滤波器的工作频率做不高。 9、请问锁相环由哪几部分组成？ 由鉴相器、环路滤波器和压控振荡器三部分组成。 10、请问RS-232C 标准的逻辑0 和逻辑1 电压范围是多少？ RS-232C 电气标准是负逻辑，逻辑0 的电压范围是+5V~ +15V，逻辑1 的电压范围是-5V ~ -15V。-5V~+5V 为不稳定区。 37、名词解释：UART、USRT、USART。 UART：Universal Asychronous Receiver/Transmitter，通用异步接收器/发送器，能够完成异步通信。 USRT：Universal Sychronous Receiver/Transmitter，通用同步接收器/发送器，能够完成同步通信。 USART：Universal Sychronous Asychronous Receiver/Transmitter，通用同步异步接收器/发送器，能完成异步和同步通信。 11、请问串口异步通信的字符帧格式由哪几部分组成？ 由起始位、数据位、奇偶校验位和停止位四部分组成。 12、请列举您知道的差分平衡电平接口。 RS422、RS485、RJ45、CAN、USB、LVDS。 13、电磁干扰的三要素是什么？ 电磁干扰源、干扰传播路径和干扰敏感设备。 14、请解释一下什么是串扰和振铃。 串扰：串扰是指一个信号被其它信号干扰，作用原理是电磁场耦合。信号线之间的互感和互容会引起线上的噪声。容 性耦合引发耦合电流，而感性耦合引发耦合电压。 振铃：是因为信号线本身阻抗不匹配导致信号发生反射和叠加，从而使信号出现了振荡波形。 15、您所遇到的需要控制单端阻抗为50 欧姆、75 欧姆的信号有哪些？您所遇到的需要控欧姆的信号有哪些？ 一般的高频信号线均为 50 欧姆~60 欧姆。75 欧姆主要是视频信号线。USB 信号线差分阻抗为 90 欧姆，以太网差分信号 线差分阻抗为100 欧姆。RS422、RS485、CAN 差分信号的差分阻抗为120 欧姆。 16、差分线走线有两个原则：等长和等距。但在实际布线中可能无法两者都完全满足，那么请问是等长优先还是等距优先？ 应该等长优先，差分信号是以信号的上升沿和下降沿的交点作为信号变化点的，走线不等长的话会使这个交点偏移，对信 号的时序影响较大，另外还给差分信号中引入了共模的成分，降低信号的质量，增加了 EMI。小范围的不等距对差分信号影响 并不是很大，间距不一致虽然会导致差分阻抗发生变化，但因为差分对之间的耦合本身就不显著，所以阻抗变化范围也是很小 的，通常在10%以内，只相当于一个过孔造成的反射，这对信号传输不会造成明显的影响。

By Toradex 胡珊逢 1). 简介 在嵌入式领域中 Watchdog 看门狗通常被作为用于应对系统或者应用意外崩溃的有效手段。其可以在程序执行出错并无法恢复的情况下，自动重启应用甚至复位整个系统，从而使系统脱离宕机状态，恢复正常业务执行。这对于涉及到人身、财产安全的应用，显得极为重要。本文将基于 NXP iMX6 嵌入式平台如何使用看门狗进行介绍，应对 Linux 系统或者应用程序意外崩溃。 本文所演示的 iMX6 平台来自于 ToradexColibri iMX6 计算机模块， iMX6 芯片自带看门狗功能，其硬件和早期的 iMX2 一致，所以看门狗驱动仍然沿用 imx2-wdt 。看门狗只支持单用户操作，即只能有一个实例来使用看门狗。因此在 Linux 系统中，用户可以选择由自己的应用直接使用看门狗，但只限于一个进程。看门狗只监控该应用，对于 Linux 本身或者其他应用则无法在意外崩溃的情况下触发看门狗复位。或者使用 systemd (183 以后的版本 ) 来操作硬件看门狗，同时为用 systemd 所管理的单元提供软件逻辑看门狗。硬件看门狗主要应对 Linux 内核以及 systemd 自身的崩溃，软件逻辑看门狗则可以用于用户自己的应用，且不受数量限制。 2). 用户应用操作 ./ 首先在 U-Boot 中设置看门狗超时时间，这里设置为 60 秒。 ------------------------ setenv defargs $defargs imx2-wdt.timeout=60 saveenv ------------------------ ./ 编译完成后运行 测试程序 。 ------------------------ root@colibri-imx6:~# ./wdt-sample-app & 627 ------------------------ ./ 终结该测试程序进程。当进程被终结后，看门狗仍旧保持运行，但是无法定时喂狗。因此，在 60s 超时后，看门狗会复位系统。 ------------------------ root@colibri-imx6:~# kill 627 root@colibri-imx6:~# watchdog: watchdog0: watchdog did not stop! + Terminated ./wdt-sample-app ------------------------ ./ 当模块由于看门狗复位时，可以从 U-Boot 启动的串口日志发现复位的原因。 ------------------------ U-Boot 2016.11-2.8.5+g02735f4004 (Dec 28 2018 - 01:54:12 +0000) CPU: Freescale i.MX6DL rev1.1 at 792 MHz Reset cause: WDOG I2C: ready DRAM: 512 MiB ------------------------ 3). Systemd 操作 a). 对于需要使用看门狗监控多个应用，可以使用 systemd 来操作。 Systemd 提供硬件看门狗和软件看门狗支持。硬件看门狗用于监控 Linux 内核以及 systemd 自身的运行，一旦出现内核崩溃的情况，看门狗超时将触发系统复位。在 systemd 中使用硬件看门狗非常简单，只需要配置 /etc/systemd/system.conf 中的 RuntimeWatchdogSec= 参数，将其设置超时时间即可。在规定时间如果没有喂狗，将触发复位。 systemd 通常会在所设置时间的一半为间隔进行喂狗。 ShutdownWatchdogSec= 则可以设置关机超时时间，如果系统在该时间内没有完成关机，也将系统复位。 ./ 为了触发内核崩溃的情况，我们需要开启内核调试的 MAGIC_SYSRQ 功能，该选项在 Toradex 默认的 Linux BSP 中是关闭的。打开后重新编译内核。 ------------------------ CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_DEBUG_KERNEL=y ------------------------ ./ 设置超时时间为 60 秒， RuntimeWatchdogSec=60 。 启动查看系统日志，显示硬件看门狗超时时间被设置为 1 分钟。 ------------------------ root@colibri-imx6:/etc/systemd# dmesg|grep watchdog systemd : Hardware watchdog 'imx2+ watchdog', version 0 systemd : Set hardware watchdog to 1min. ------------------------ ./ 然后我们用下面命令触发内核崩溃。 ------------------------ /proc/sysrq-trigger ------------------------ ./ 一分钟以后，由于 systemd 没有对进行喂狗操作，系统将复位后重新启动。 b). 除了硬件看门狗外， sytemd 还提供软件看门狗，每个 systemd service 都可以使用。 service 需要读取 WATCHDOG_USEC= 参数，确定看门狗超时时间，并在该时间范围内使用 sd_notify("WATCHDOG=1") 喂狗，同样喂狗的时间间隔为 WATCHDOG_USEC= 所设置的一半。 ./ 用户只要在对应的 systemd service 文件中设置 WatchdogSec= 参数即可，而 WATCHDOG_USEC= 将根据前面的参数自动被设置。在应用程序中以 WatchdogSec/2 的间隔调用 sd_notify 函数发送 "WATCHDOG=1" 进行喂狗操作。例如 ------------------------ // Systemd servier 文件 (/etc/systemd/system/test.service) ，用于启动用户应用 Description=Watchdog Test service ExecStart=/home/root/wdt-sw-test WatchdogSec=30s Restart=on-failure StartLimitInterval=5min StartLimitBurst=4 StartLimitAction=reboot WantedBy=multi-user.target ------------------------ ./ 用户应用 wdt-sw-test.c ，并定期执行喂狗操作（编译的时候需要使用 -lsystemd 链接 systemd 库文件）。 在应用初始化后需要通知 systemd 管理器本应用正常启动， sd_notify (0, "READY=1"); 。然后根据 WATCHDOG_USEC 变量设置喂狗间隔。在应用中我们将模拟一次超时喂狗，从而引起应用重启。 ./ 下面是运行日志。起初应用程序 wdt-sw-test 由 systemd 加载启动， PID=396 ，并以 15s 间隔喂狗（该时间源自 WatchdogSec=30s ）。当喂狗超时后， systemd 会发送信号 SIGABRT 终止该进程，并重启该应用，新 PID=647 。 ​ ./ 在 service 文件中，我们还配置了 StartLimitBurst 和 StartLimitInterval 以及 StartLimitAction 参数。这使得在 StartLimitInterval 时间内应用启动次数超过 StartLimitBurst 后，将不被允许再次启动，并触发 StartLimitAction 的操作。具体描述请参考 systemd.unit 。 3). 总结 看门狗对于关键应用，以及大多数的一般应用来讲是一个很重要的功能，其能够应对 Linux 系统或者应用崩溃的情况，避免用户设备处于失控的状态。当整个系统只有一个嵌入式设备作为决策控制单元时，对于关键的安全应用，根据单一故障准则，我们还建议引入辅助控制单元，例如额外的 MCU 等做同步监测，或者使用保险丝、热电偶等，当出现超限情况，能够执行紧急操作，从而进一步提高设备的安全性。

I have written extensively about designing ultra-low power systems that operate from coin cells. Unfortunately, a lot of vendor information is gilded with marketing malarkey; we engineers have to separate fact from aspiration and design using worst-case analysis.   Quite a few people have written asking about using watchdog timers (WDT) in battery-operated systems that achieve years-long life by snoozing 99+ percent of the time. The system may be dead to the world for hours – how does one service a WDT when the code isn’t running?   Why would you want to? How can the software crash when it’s not running?   The answer is that the code can fail while awake and accidently enter a sleep state. Running the WDT during sleep ensures the system will recover.   One could wake up once a minute or so and tickle the watchdog. Generally that only requires a handful of instructions. Even when running from a 32 kHz clock (typical for ultra-low power sleep modes) the tickle will only need a ms or so of awake time. If the MCU consumes 50 uA while servicing the WDT that’s just 7.5 uAh per year of operation. Given that a CR2032 coin cell has about 220 mAh of capacity, the energy needed for managing the WDT is insignificant.   But the reality is a bit more complex. We have to work with real parts, not idealized devices.   I looked at a typical microcontroller from Microchip, picked at random from their incredibly diverse selection of “XLP” (extremely low power) devices. The PIC16LF1704/8 is a nice 8 bitter with gobs on on-board I/O, including a watchdog timer. In the low-power sleep mode the WDT consumes 14-17 uA. I started engineering when a microprocessor needed a huge honking power supply, so this is an incredibly small number. But it’s too much for long-lived coin cell operation. That compendium I referenced demonstrates that for 10 years of life from a coin cell the average current consumed can’t exceed 2.5 uA. That watchdog is unusable in this environment.   (I didn’t do an exhaustive search; possibly other MCUs from Microchip have lower-current WDTs. And I commend them for publishing these worst-case numbers; too many other vendors don’t.)   A competing MCU from TI, the MSP430F11x1a, takes only 1 to 3.4 uA in the lowest-power sleep that still has an oscillator running (to support the WDT). Nice, but 3.4 uA is far too much for these applications. The better figures assume Vdd is 2.2 volts and it’s not hot. No incremental current is listed for turning on the watchdog, which suggests that is included in these figures. However, the user’s guide reads “When the watchdog timer is not required, the WDTHOLD bit can be used to hold the WDTCNT, reducing power consumption.” That sounds like there is some undocumented hit for using that peripheral. Is it a nanoamp or do you have to run jumper cables to a car battery? Sans data, engineers are left adrift.   Other vendors are equally vague.   Since the code can’t crash while sleeping, leave the WDT turned off during those long periods. Enable it while awake. Running, a crash will be mediated by the operating WDT. The upside of this approach is that, since the MCU is awake for such short periods, the current consumed by the WDT is insignificant and won’t drain the battery.   While awake, of course, a crash could vector to the code that disables the watchdog before going to sleep. Instead, structure the code to initialize a variable to a known value, and add offsets to it while running. That could be done in functions that are always called. Before executing the SLEEP instruction check to see if that variable contains a value that indicates the code executed correctly. Take recovery action if the variable is not correct. Or, if basically the same code runs during each awake cycle, use a timer to measure execution time; error if it deviates much from nominal.   There are other failure modes. The firmware could be perfect, but an external event – EMI or a cosmic ray impact – may scramble the MCU’s neurons. Perhaps the program counter gets altered. When the MCU wakes up it will resume operation at a random address without re-enabling the WDT. Or maybe the event flips a bit in the sleep logic so the microcontroller never wakes up.   Essentially, one would need a watchdog that operates during sleep times to counter these threats. Internal WDTs use too much current. I can’t come up with a circuit that would consume the microamp or less one can budget to a watchdog. Some of you are building long-lived battery-operated devices that sleep most of the time. For high-reliability applications, how do you implement a watchdog timer?