完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
你好！
我使用的PSoC3设备，我放置了一个16位UDB上/下计数器，计数和方向HW输入。 周期为65534（max）。我不使用任何HW输出从这个计数器，但是，当时钟输入连接到总线时钟，计数输入连接XORD从输入引脚的值和一个寄存器位用来改变计数敏感的边缘（双同步在每个引脚，约200至400赫兹）。 在计数时，我使用反Oracle Read（）函数轮询计数器。 不时地，我从这个函数中得到不正确的值。这是我从串行通信输出日志的一个例子： 轮询计数器从1823向下计数。一旦接近769（我可以看到整个日志序列正确计数没有问题），我得到一个512，然后返回741下一个投票，这发生在一段时间后（不改变计数器方向，该设备正在检测条件和停止操作，由于意外的计数值，比SeJiNG状态）。 这只是一个正在发生的事情的例子，它似乎是非常随机的，但是在我的代码中很难重现。 在这一点上，我的代码是相当大的；我应该考虑用一个较小的例子来复制这个问题，但是首先我想问一下我是否有任何错误，或者我应该使用不同的方法来读取UDB计数器的FIFO，或者如果有任何已知的问题涉及到这个计数器。 最好的问候， 斯蒂法诺 以上来自于百度翻译 以下为原文 Hi! I am using a PSoC3 device where I placed a 16 bit UDB up/down counter, with count and direction HW inputs. Period is 65534 (MAX). I am not using any HW output from this counter, but, while clock input is connected to bus clock, count input is connected XORed with value from input pin and a register bit used to change count sensitive edge (double sync on each pin, about 200-400Hz). While counting, I am polling counter using Counter_ReadCounter() function. From time to time, I am getting incorrect values from this function. This is one example of my output log from serial communication: Polling counter in down count from 1823. Once near 769 (I can see the whole log sequence that counted correctly without issues), I get once 512, then back 741 on next poll, that happens after some time (without changing counter direction, the device is detecting condition and stopping operation due to unexpected count value, than is showing status). This is just one example of what is happening, and it seems issue is quite random, but it is very hard to reproduce in my code. At this point, my code is quite large; I should consider trying with a smaller example that aims to reproduce the issue, but first I am trying to ask if there is anything I am doing wrong or if I should use a different approach to read FIFO of UDB counter, or if there is any known issue related to this counter. Best regards, Stefano 
0
|
|
相关推荐
13个回答
|
|
|
它看起来像是捕获16位下溢的下半部（当从768下降到767），计数器的下半部分首先被读取（导致0x00仍然），然后读取更高的部分（导致0x02已经），因此寄存器被读取为0x2。00，它应该是0x2FF。
我不希望这种情况发生，因为反Oracle Read OR（）首先进行捕获，然后从FIFO返回结果。您使用的是哪个版本的创建者，以及计数器组件的哪一个版本？当前的数据表只在版本2开始，所以旧版本可能在这方面有问题…（对于V2.0，该组件已被重新实现为同步计数器）。 还注意到（在V2.30），16位UDB计数器的最大频率是33 MHz。 以上来自于百度翻译 以下为原文 It looks like you are capturing exact the same moment the lower half of the 16 bits underflow (when counting from 768 down to 767), and the lower half of the counter is read first (resulting in 0x00 still), and then the higher part is read (resulting in 0x02 already), so the register is read is 0x200 where it should have been 0x2ff. I would not expect this to happen, since Counter_ReadCounter() first does a capture, and then return the results from the FIFO. Which version of Creator are you using, and which version of the counter component? The current data sheets starts at version 2.0 only, so maybe older versions have issues in this regard... (for V2.0 it is stated that the component has been reimplemented as synchronous counter). Also note that (in V2.30) the maximum frequency for a 16bit-UDB-Counter is 33MHz. |
|
|
|
|
|
谢谢你的回复。
如在框中所示，我使用PSoC Creator 2.2组件包5。它应该是最新版本。 计数器版本，内置组件选项卡，为2.30。 输入计数频率小于500 Hz，时钟输入为24MHz。 如果有可能在计数输入上的毛刺可能导致这种行为发生，我可以添加外部RC滤波器或数字去毛刺滤波器。但是也许有一个解决办法（例如等待一些时钟周期）以确保数据在FIFO寄存器中正确加载… 以上来自于百度翻译 以下为原文 Thanks for your reply. As shown in about box, I am using PSoC Creator 2.2 Component pack 5. It should be the latest version. Counter version, in Built-in tab of component, is 2.30. Input count frequency is less than 500Hz, while clock input is 24Mhz. If there is a chance that a glitch on count input might cause this behavoir to happen, I could add an external RC filter or a digital deglitch filter. But maybe there is a workaround (e.g. wait some clock cycles) to ensure that data is properly loaded in FIFO registers... |
|
|
|
|
|
也许我错过了什么。柜台是否连续营业？
你的轮询实际上是一个采样门，投票不是同步事件，而是服从ISR和 在其他HW上的固件活动，所以读计数器永远不会产生随机结果吗？ 我一定错过了什么…… 问候，Dana。 以上来自于百度翻译 以下为原文 Maybe I am missing something. Is the counter running continuously ? Your polling is in effect a sampling gate, the poll not a sync event, and subject to ISR and firmware activity on other HW, so reading counter would never produce random results ? I must be missing something...... Regards, Dana. |
|
|
|
|
|
我在主应用程序循环中查询计数器。
有一个ISR读取这些计数器，但是在读取之后，系统被重新设置。这个ISR只是被称为电源故障。这不是发生了什么。 我正在读取来自外部簧片开关的一些脉冲。这些CPU通过R—C滤波器去抖动。 正如我所说的，系统实际上比这更复杂。在UART端口上有一个串行通信服务，其中一个外部设备请求计数器的增量值，这个板响应这个请求。 但是，请记住，我正在使用16字节的FIFO缓冲器用于UART（因此可能会有由串行通信块自动产生的中断），整个通信服务（读、检测命令和应答）和软件读计数器的相关操作是在MAI中完成的。应用程序循环。 不应该有其他ISR。 计数器连续运行。阅读价值时，我无法阻止它。 大多数时候阅读计数器工作很好。这是每一次，也许，100K次，作为经验法则。 以上来自于百度翻译 以下为原文 I am polling counter just in main application loop. There is an ISR that reads these counter but, after reading, system is resetted. And this ISR is just called on power fail. This is not what happens. I am reading a number of pulses from an external reed switch. These inpus are debounced by an R-C filter. As I said, system is actually more complex than that. There is a serial communication service on UART port where an external device asks for incremental value of counter and this board replies to this request. But, kept in mind that I am using 16 bytes FIFO buffers for UARTS (and thus there might be interrupts generated automatically by serial communication blocks), the whole communication service (read, detect command and reply) and the related operation of reading counter by software is done in the main application loop. There shouldn't be other ISRs. Counter is running continuously. I cannot stop it while reading value. Most of the times reading counter works fine. This happens about once every, maybe, 100k times, as rule of thumb. |
|
|
|
|
|
AddiaRead反（）方法首先执行当前计数器值的捕获，然后读取捕获的值。
因此，在捕获过程中出错（因为对于16位计数器，使用2个UDB，它们需要在同一时刻捕获）。或者2个读数相互混合，这意味着捕获在读取发生的同时被执行。 以上来自于百度翻译 以下为原文 @dana the Counter_ReadCounter() method first executes a capture of the current counter value, and then reads the captured value. So either during capture something goes wrong (because for a 16bit counter, 2 UDBs are used, and they need to capture at exactly the same moment). Or 2 reads are intermixed with each other which means that a capture gets executed the same moment when a read occurs. |
|
|
|
|
|
你可以做些什么来寻找可能的原因：
增加计数输入上的频率，并检查这是否增加了发生的问题的概率（如果是的，在捕获过程中看起来像一个故障），使用固定函数计数器，并检查它是否在那里发生（仅当计数时钟来自PSoC时钟时）在所有地方发生。在计数器可以访问（特别是ISRS）的情况下，切换一个LED来查看它们是否真的未被执行，您可以在这里发布您的项目，所以我们可以查看一下吗？ 我不认为这有助于同步计数输入，所以一个故障过滤器不会帮助（但你可能会测试它仍然是肯定的：） 以上来自于百度翻译 以下为原文 What you could do to find possible reasons:
I don't think it has to do with syncing the count input, so a glitch filter won't help (but you might test it nonetheless to be sure :) |
|
|
|
|
|
在查看组件源代码、Verilog文件和数据路径配置（这是一个很好的借口来阅读更多关于这个东西：）我觉得计数器应该正常工作。数据通路被正确地链接在一起，并且从计数器值（存储在累加器A0中）到FIFO的传输应该是原子的（因为执行捕获的代码只访问LSB）。我怀疑CPU是否足够快地执行FIFO寄存器的后续读取比UDB传输的值快（或者CPU时钟高于24MHz）？.
以上来自于百度翻译 以下为原文 After looking at the component sources, the verilog file and the datapath configuration (a good excuse to read up a little bit more about this stuff :) it looks to me that the counter should work properly. The datapaths are properly chained together, and the transfer from the counter value (stored in the accumulator A0) to the FIFO should be atomic (since the code doing the capture accesses the LSB only). And I doubt the CPU is fast enough to execute the subsequent read of the FIFO registers faster than the UDBs transfer the values (or do you clock the CPU higher than 24MHz?). |
|
|
|
|
|
非常感谢您的关心和建议。
对不起，我不能在这里发布完整的项目（不是我的，是我们的客户）。如果我有时间，我会尝试在一个较小的应用程序子集上重现这个问题。MistelyCalm和BUS时钟都是24MHz。没有更快的时钟。 同时，我会尝试（我不喜欢工作杂耍）给这些错误条件添加一些陷阱点。 只是另一个问题： 是否有可能在翻转期间触发捕获事件？如果捕获恰好触发了相同的时钟边沿，增加了较不重要的（FF）位，并导致侧翻（+ 1到高位），会发生什么情况？这不会导致意外的行为吗？ 以上来自于百度翻译 以下为原文 Many thanks for your interest and your advices. I'm sorry but I cannot post the full project here (it's not mine, it's for one of our customers). If I have time, I'll try to reproduce the issue on a smaller subset of the application. MASTER_CLOCK and BUS_CLOCK are both 24Mhz. There are no faster clocks. In the mean time, I'll try (I don't like work-arounds) to add some trap points to these error conditions. Just another question: is it possible that a capture event is triggered during rollover? What happens if capture is triggered exactly the same clock edge that increases the less significant (FF) bits and causes rollover (+1 to the upper bits)? There is no chance that this could cause an unexpected behavior? |
|
|
|
|
|
这个场景正是我试图描述的：（我只把它称为下溢而不是翻转）。但是由于计数器应该是同步的（根据描述），并且捕获事件本身是原子的（至少根据技术参考手册），它不应该发生。但这是我最好的解释…
当发生频率较高时，它看起来更像是这种情况。如果不这样，那就是另外一回事了。 以上来自于百度翻译 以下为原文 This scenario is exactly what I tried to describe above :) (I just called it underflow instead of rollover). But since the counter should be synchronous (according to the description), and the capture event itself is atomic (at least according to the technical reference manual), it should not happen. But it is the best explanation I have... When it happens more often with a higher count-frequency, it looks like this scenario. If it don't, the it is something else. |
|
|
|
|
|
这是我第一次尝试在更友好的环境中复制bug。
我附上这个邮政系统日志和应用程序代码。 如果我没有做错什么（而且发生在从原来的代码变成这个的时候） 这是系统设置： 1。RX系列接收机应用于RXAUXYS3 2。C1和C2输入用作计数器输入。实际上，我正在尝试一个信号发生器，1kHz，方波应用到C2。 三。我将调试陷阱添加到系统日志中，这就是结果。这里有一些调试陷阱的样本（十六进制格式的数字） 4。调试UART仍然使用中断。我将尝试使用来自系统时钟的时钟来代替外部信号发生器来进行输入。 高估 FF至101跃迁，杂散1FF读取A7FF到A801，假A8FF读取EDFF到EE00，杂散EEFF读下计数 C900到C8FF，杂散C800 B800到B7FF，读取B700 1700至16FF，读取1600奇怪的事情是，这并不总是发生，而有一个较低的字节下溢或溢出…大多数时间价值是正确的。 我希望我犯了愚蠢的错误，但似乎这是一个更复杂的问题… 你在我的代码中看到什么问题了吗？有什么想法吗？ 反测试 307.4 K 以上来自于百度翻译 以下为原文 Here is my first attempt to replicate the bug in a more friendly environment. I attached to this post system log and application code. If I'm not doing anything wrong (and it happens since when changing from original code to this) This is system setup: 1. An RX serial receiver is applied to RX_AUX_3 2. C1 and C2 inputs are used as counter inputs. Actually I am trying with a signal generator, 1kHz, square wave applied to C2. 3. I added debug traps to system log, and this is the result. Here there are some samples of these debug traps (number in HEX format) 4. There are interrupts used by debug UART still active. I'll try to use clock derived from system clock to counter input instead of external signal generator. UP COUNTING
I hope I made supid mistakes, but it seems this is a more complex issue... Do you see any issue in my code? Any idea?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我建议开一个支持案例。我看不出你的项目或代码有什么问题。
我现在的猜测是：通过执行这个语句，首先，反Oracle RealValueAd（）捕获当前计数器值： （空隙）对1； 这访问计数器LSB，并且UDB被配置为将其累加器（保持计数器值）转移到FIFO（作为捕获寄存器）。由于形成计数器的2个UDB是链式的，所以MSB也被捕获。 但是发生的是，MSB在某种程度上被捕获在你的日志中，你可以看到MSB已经被更新，而LSB仍然有旧的值。当捕获发生在翻转发生的同一时刻（当只有两个UDB改变）时，这会发生，所以捕获不是原子的，或者计数器不是同步的。我想这两个都是组件中的错误。 以上来自于百度翻译 以下为原文 I suggest to open a support case. I cannot really see something wrong in your project or code. My current guess is this one: Counter_ReadValue() first captures the current counter value, by executing this statement: (void)Counter_1_COUNTER_LSB; This accesses the counters LSB, and the UDB is configured to transfer its accumulator (which holds the counter value) to the FIFO (which acts as capture register). And since the 2 UDBs forming the counter are chained, the MSB is captured also. But what happens is that the MSB is somehow captured late - in your log one can see that the MSB has been updated already while the LSB still has the old value. This happens when the capture is done in the same instant the rollover happens (because only then both UDBs are changed) So either the capture is not atomic, or the counter is not synchronous. Both are bugs in the component, I suppose. |
|
|
|
|
只有小组成员才能发言，加入小组>>
715个成员聚集在这个小组
加入小组1896 浏览 1 评论
1651 浏览 1 评论
3401 浏览 1 评论
请问可以直接使用来自FX2LP固件的端点向主机FIFO写入数据吗？
1567 浏览 6 评论
1379 浏览 1 评论
CX3连接Camera修改分辨率之后，播放器无法播出camera的画面怎么解决？
180浏览 2评论
179浏览 2评论
使用stm32+cyw43438 wifi驱动whd，WHD驱动固件加载失败的原因？
318浏览 2评论
344浏览 1评论
58浏览 1评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1995
评论
淘帖
2050
