S32K312 FlexCAN – 启用 AEN 和总线关闭恢复时，使用 RTD 7.0.1 实现发送消息缓冲区中止 您好，NXP团队， 我正在使用NXP S32K312评估板和S32K3 RTD 7.0.1（AUTOSAR 4.9.0）。我正在使用RTD API FlexCAN_Ip_Send()和FlexCAN_Ip_AbortTransfer()测试FlexCAN发送消息缓冲区中止功能。 我的测试表明，中止功能没有按预期运行。我已附上项目文件、MEX 配置和测试代码供您参考。 我希望您能就以下三个问题提供指导。 1. 中止多个发送消息缓冲区 在我的第一次测试中，我使用多个消息缓冲区传输消息，然后对所有这些缓冲区发出中止请求。测试代码如下所示。 /* Transmit messages using MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_Send( INST_FLEXCAN_0, lMb_u8, &tx_info, 0x123U, &dummyData[0] ); } /* Request abort for MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_AbortTransfer( INST_FLEXCAN_0, lMb_u8 ); } 所有传输请求都使用相同的 CAN ID，即0x123 ，而消息缓冲区索引从 0 到 39 不等。 MCR [AEN]位设置为 1，启用了中止机制。但是，即使我发出中止消息缓冲区的请求，所有消息仍然可以在 PCAN-View 中看到。 我的预期是，仍在等待传输的消息应该被中止，而已经完成传输的消息则不能被中止。 请问您能否澄清以下问题？ 对于在多个消息缓冲区上进行传输，然后中止所有待处理的传输，是否有推荐的顺序？ 2. 使用单个消息缓冲区中止传输 为了找出问题所在，我创建了第二个测试，该测试仅使用消息缓冲区 8。 序列如下： 为 MB8调用FlexCAN_Ip_Send() 。 使用FlexCAN_Ip_GetTransferStatus()检查传输状态。 如果发送成功且传输状态为FLEXCAN_STATUS_BUSY ，则对 MB8调用FlexCAN_Ip_AbortTransfer() 。 再次读取传输状态并检查硬件寄存器。 发送 API 返回FLEXCAN_STATUS_SUCCESS ，中止前的状态检查报告FLEXCAN_STATUS_BUSY 。但是，中止 API 返回FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS ( 0x5 )。 在调试 RTD 实现时，我发现返回状态源自FlexCAN_AbortTxTransfer() 函数内部的以下条件： FlexcanMbConfig = *FlexcanMb; /* Check if the MBs have been safely inactivated */ if ((uint32)FLEXCAN_TX_INACTIVE == ((FlexcanMbConfig & FLEXCAN_IP_CS_CODE_MASK) >> FLEXCAN_IP_CS_CODE_SHIFT)) { /* Transmission has occurred */ Result = FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS; } 在我的当前配置中，消息缓冲区位于内存浏览器中的0x40304100地址。中止请求发出后， CODE字段显示为0x8 ，这对应于非活动/已发送状态，而不是预期的中止代码0x9 。 我还为FlexCAN_AbortTxTransfer()函数中的以下语句设置了一个断点： TimeStart = OsIf_GetCounter( FLEXCAN_IP_SERVICE_TIMEOUT_TYPE ); 此时， IFLAG1[8]已设置。 在当前的RTD实现中，中止序列会将FLEXCAN_TX_ABORT ( 0x9 )写入消息缓冲区的CODE字段，然后轮询相应的消息缓冲区中断标志。中止辅助函数返回后， FlexCAN_Ip_AbortTransfer()中的FlexCAN_ClearMsgBuffIntStatusFlag()函数会清除该标志。 我担心的是，在发出中止请求之前，中断标志可能已经因已完成的传输而被设置。如果真是这样，轮询循环就可以立即退出，而无需等待新的中止完成事件。但是，我尚未确认这是否是我的问题的原因。 3. 总线关闭恢复（自动恢复功能已禁用） 在另一项测试中，我禁用了自动总线关闭恢复功能，并尝试通过应用程序处理恢复。 当总线断开时，我目前的做法是先取消初始化 FlexCAN 驱动程序，然后再重新初始化。但是，在此之后，后续对FlexCAN_Ip_Send()的调用无法成功发送消息。 当自动总线断开恢复功能被禁用时，请问推荐的恢复步骤是什么？ 具体来说： 取消初始化和重新初始化是否足以使 FlexCAN 控制器从总线关闭状态恢复？ 在反初始化之前，是否应该中止或显式清除所有未处理的 TX 消息缓冲区？ 重新初始化后，消息缓冲区在传输前是否必须重新配置或初始化？ 在控制器能够再次发送数据之前，是否需要执行与ESR1状态、 MCR 、 CTRL1[BOFFREC] 、中断标志或 RTD 内部传输状态相关的任何步骤？ 从总线关闭状态恢复的推荐顺序是什么？同时要确保没有过期的 TX 传输或邮箱状态阻止后续传输。 我已附上测试项目、MEX 配置和相关源代码，以便审查配置和 API 使用情况。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 嗨@Yogs 我已将您提出的三个问题的答案总结如下： （内容较多，格式有点混乱。） Q1. 关于“Flexcan 中止”问题。 首先，您需要了解 FlexCAN 中止机制仅对仍处于挂起状态的 TX 消息缓冲区 (MB) 有效。 关于你的第一次测试： 首先激活MB0； FlexCAN 开始扫描并继续传输 MB0 的内容； 同时，CPU继续配置MB1、MB2、…、MB39； 当 CPU 最终到达第二个循环时，最初的一组 MB 可能已经传输完毕。 在总线负载低、成功接收到 ACK 以及经典 CAN 典型的 8 字节有效载荷等条件下， 40帧的传输可以很快完成。 同样的情况也适用于第二个测试，如果总线处于空闲状态，FlexCAN 很可能已经完成传输。 在 CPU 执行中止命令之前。 因此，你的两个测试都不能证明任何事情。 要正确验证中止操作，需要特意创建一个明确的“待处理”窗口，而不是依赖 CPU 的执行速度。 例如： 配置另一个 CAN 节点，使其使用更高优先级的 ID 持续占用总线，从而使目标消息缓冲区 (MB) 保持处于挂起状态，然后触发中止。 Q2：为什么单 MB 测试最初返回 BUSY，但在中止请求时返回 NO_TRANSFER_IN_PROGRESS？ 两者之间可能会出现短暂的状态不匹配： `FlexCAN_Ip_Send()` 将 RTD（运行时驱动程序）状态设置为 `BUSY`。 硬件开始传输。 帧传输完成；硬件将 MB（消息缓冲区）代码更新为 `0x8` 并设置 `IFLAG`。 如果 TX IRQ 处理程序尚未执行，或者在断点调试期间系统暂停，则 RTD 状态结构可能仍保持为“BUSY”。 此时会调用“中止”操作。 在内部，`Abort` 函数读取 MB CODE 并发现它已经是 `0x8`。 它返回 `FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS`。 因此：`GetTransferStatus() = BUSY` 且 `FlexCAN_Ip_AbortTransfer() = NO_TRANSFER_IN_PROGRESS` 并非一定相互矛盾。 前者可能反映软件记账，而后者则确认实际的硬件代码。 Q3. 总线停驶恢复 完全可以通过重新初始化 CAN 模块来从“总线关闭”状态恢复。 要手动执行“总线关闭”恢复，应用层必须首先停止数据传输，并取消或丢弃所有待处理的发送 (TX) 请求（中止）。 随后，控制器必须进行完全反初始化，然后再进行重新初始化。 随后，应重新配置应用层接收（RX）消息缓冲区（MB），并清除任何过时的消息缓冲区标志、错误标志和软件传输状态。 在恢复传输之前，应用层应验证控制器是否已退出“冻结”或“未就绪”状态，并确保发送消息缓冲区（TX MB）和“准备传输”（RTD）状态均未处于“忙碌”状态。 既然你提到你的测试失败了，那么你很可能忽略了上面提到的步骤。我在附件中没有找到任何关于总线断开恢复程序的信息；如果您对此仍有疑问，请随时与我分享您的测试项目，我可以查看并帮助您检查。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 关于问题1，我想澄清一下我的测试条件。 我使用的 CAN 波特率为 500 kbps ，一个具有 8 字节有效载荷的经典 CAN 帧 在总线上传输 大约需要 300 µs 。 在我的测试中，我首先通过相应的TX消息缓冲区提交消息，然后立即执行中止函数。中止函数会遍历相应的消息缓冲区，并对每个缓冲区调用FlexCAN_AbortTxTransfer()函数。 因此，中止请求是在传输请求发出后立即针对相应的消息缓冲区发出的，而不是故意延迟发出的。 我明白，在中止循环到达之前，前几条消息可能已经传输完毕。但是，考虑到大致的传输持续时间和提交的消息数量，我预计在发出中止请求时，一些较晚的消息缓冲区仍然会有待处理的传输。 您能否帮我了解一下，是否存在其他硬件条件或时序因素会导致这些待处理消息无法中止？ Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 嗨@Yogs 这是你的代码中“中止 MB”的默认序列； for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,lMb_u8); } 我已将其修改为“40 - 1Mb_u8”。 for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,40 - lMb_u8); } 以下是我的测试结果。 我只收到了两帧数据；其他所有 MB 的数据都已成功中止。 此次验证的结果足以证实我之前的假设：在你执行中止 MB 操作之前，当前的 MB 已经成功发送。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 您好， 谢谢你的解释。我理解了您的建议，并测试了反向中止序列。正如您所说，这种方法效果更好：我只在总线上收到两个帧，而其余消息都成功中止了。 但是，我对这种行为有一些疑问。 1. 为什么需要逆向堕胎？ 这两个循环本质上不都是在执行相同的操作吗，只是执行顺序不同？ 能否解释一下为什么从最高的邮箱索引开始中止操作会产生如此显著的影响？这是否与 FlexCAN 内部扫描或选择 TX 消息缓冲区的顺序有关？ 反向顺序中止是硬件要求，还是仅仅是一种提高中止待处理消息概率的推荐方法？ 2. 如果要中止单个消息缓冲区呢？ 我还测试了仅使用一个消息缓冲区时的中止功能： FlexCAN_Ip_Send( INST_FLEXCAN_0， 0U, &tx_info， 0x123U， &dummyData[0] ）； FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0, 0U); 我测试了执行 FlexCAN_Ip_Send() 和调用 FlexCAN_Ip_AbortTransfer() 之间的时间。大约需要 10.3 微秒。 然而，即使间隔时间很短，消息仍然会在 CAN 总线上传输。 我还使用 PCAN-View 中的高优先级消息保持了合理的总线负载，但单消息中止仍然不成功。 作为对比，当我使用多个消息缓冲区进行传输，然后按相反的顺序中止它们时，测得的序列持续时间约为 9.3 毫秒，总线上只接收到两个帧，其余消息都被中止。 这就引出了另一个问题：为什么即使在发送 API 返回后大约 10.3 µs 发出中止请求，单消息中止仍然会失败，而多邮箱反向顺序方法却能成功中止大多数消息？ 在发出中止请求之前，该单条消息是否可能已经传输到内部 TX 串行消息缓冲区 (TX SMB)？ 我希望您能解释一下硬件是如何处理这种情况的，以及如何可靠地测试单个消息缓冲区的中止机制。

IW610 – BLE 编码 PHY 被动扫描随机停止接收广播报告 你好， 我们正在开发一款基于NXP IW610 （Quectel FGA66X，USB 版本）的设备，采用Sunplus SP7021作为主机处理器，运行 Linux 内核 5.10。 我们遇到一个问题，编码 PHY 上的 BLE 被动扫描会随机停止接收广播报告。该问题间歇性出现：扫描可能仅持续一小时就停止，也可能持续超过 24 小时不间断。 我测试了 Quectel 提供的固件/驱动程序包 (18.99.8.p3) 和 NXP GitHub 上提供的更新版本 (18.99.8.p136)。我还尝试了多种驱动程序参数配置，但问题仍然存在。 我使用以下 HCI 命令在编码 PHY 上配置并启用被动扩展扫描： # LE Set Extended Scan Parameters hcitool cmd 0x08 0x0041 0x00 0x00 0x04 0x00 0x10 0x00 0x10 0x00 # LE Set Extended Scan Enable hcitool cmd 0x08 0x0042 0x01 0x00 0x00 0x00 0x00 0x00 经过一段随机时间后，该模块停止通过 HCI 报告接收到的 BLE 广播数据包。hciconfig报告模块已启动并正在运行。 我也启用了 mbt_drvdbg=0xFF，但我还没有找到任何迹象表明是什么原因导致扫描停止。内核日志中没有明显的崩溃、固件故障或错误信息。 只需再次发出上述两个 HCI 命令即可恢复扫描。无需 RESET 或重新加载蓝牙模块。重新启用扫描后，蓝牙模块可以再次正常工作，但只能维持一段时间，而且时间长短无法预测。 所以我的问题是： 这是IW610固件或蓝牙驱动程序的已知问题吗？ 关于编码 PHY 的被动扫描，是否存在任何已知的限制或特定的配置要求？ 我还能启用或捕获哪些其他信息来帮助确定原因？还有其他值得尝试的固件或驱动程序调试选项吗？ 除了定期禁用和重新启用扫描之外，还有其他已知的解决方法吗？ 任何建议或指导都将不胜感激。 谢谢！ Re: IW610 – BLE Coded PHY passive scanning randomly stops receiving advertising reports 您看到的症状看起来像是 IW610 中已知的一类问题：编码 PHY 扩展扫描状态机可能会静默停滞，而控制器仍然报告 UP。重新发出两个 HCI 命令总是可以恢复它，而且 Quectel 的 18.99.8.p3 和 NXP p136 固件都会出现这种情况，这表明是固件/驱动程序错误，而不是主机端问题。 以下是最有效的后续步骤。 1. **尝试使用更安全的扫描参数集** 您当前的命令使用 ScanInterval=ScanWindow=0x0010（10 毫秒），实际上是对编码 PHY 进行连续扫描。这可能会推动 RX 调度器。尝试使用较小的窗口，例如： ``` hcitool 命令 0x08 0x0041 0x00 0x00 0x04 0x00 0x40 0x00 0x20 0x00 ``` 如果可能的话，也测试 Phys=0x05 (1M + Coded)，看看是否只有在纯 Coded PHY 的情况下才会出现停滞。 2. **发生停滞时捕获正确的日志** 启用详细动态调试： ``` echo '文件 hci_core.c+p' > /sys/kernel/debug/dynamic_debug/control echo '文件 hci_event.c+p' > /sys/kernel/debug/dynamic_debug/control echo '文件 btusb.c+p' > /sys/kernel/debug/usb/btusb/control echo '文件 mbt*.c+p' > /sys/kernel/debug/dynamic_debug/control ``` 同时运行 `hcidump -i hci0 -w scan.log` 和 `btmon -w btmon.log`。扫描停止后，立即检查： - 静默前的最后一个 HCI 事件（查找 LE 广播集终止、LE 扫描超时、硬件错误或命令不允许）。 - 主机是否仍在发送 ACL/ISO 流量。 - USB URB 状态（`dmesg | grep -i usb` 和 `cat /sys/kernel/debug/usb/devices`）。 还要收集 RSSI、温度和 USB 总线负载——如果卡顿与温度或总线拥塞相关，则表明存在其他根本原因。 3. **监控脚本作为权宜之计** 由于恢复只是重新启用扫描，因此用户空间中的监视程序目前是最可靠的解决方法。最基本的逻辑： ```bash #!/bin/bash LOG=/tmp/bt_scan_watch.log 当真时；执行 # 检查我们是否在过去 30 秒内收到广告报告 if ! hciconfig hci0 leadv 2>/dev/null | grep -q "LE Scan"; then echo "$(date) - 扫描停止，正在恢复" >> $LOG hcitool 命令 0x08 0x0042 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 睡眠 1 hcitool 命令 0x08 0x0041 0x00 0x00 0x04 0x00 0x40 0x00 0x20 0x00 hcitool 命令 0x08 0x0042 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 菲 睡眠30 完毕 ``` 这样可以避免控制器完全 RESET，并保留 USB/固件状态以进行调试。 4. **需要向恩智浦/移远讯通提供哪些信息** 如果您需要官方修复方案，请准备一个最小可复现场景： - 一台设备持续发送编码 PHY 扩展广播。 - IW610 仅处于被动扩展扫描状态（无连接，无 Wi-Fi 流量）。 - 来自 hcidump、btmon、dmesg 和 USB 跟踪的日志，涵盖了停滞时刻。 - 固件版本和确切的 HCI 命令序列。 提到 18.99.8.p3 和 18.99.8.p136 都表现出相同的行为，并且只有重新发出扫描禁用/启用命令对才能恢复。 5. **其他固件调试选项** 除了 `mbt_drvdbg=0xFF` 之外，还要检查驱动程序是否为 BLE RX 路径公开了 `drvdbg` 掩码（例如，`0x10` 用于扫描，`0x20` 用于 PHY 切换）。如果模块支持，通过 UART 或 USB 供应商命令启用控制器端日志记录可以揭示主机 HCI 层看不到的内部状态机转换。 截至目前，NXP 尚未在已发布的版本固件软件包中公开记录针对 IW610 的特定编码 PHY 扫描停顿修复方案。如果你能捕获到显示停顿之前最后一个 HCI 事件的跟踪信息，那将是 NXP 工程团队最有力的线索。

Wordle vs Scrabble: Which Word Game Is Better for Brain Training? Wordle and Scrabble are two of the most popular word games in the world. Depending on the skills you are looking to train and how much time you can dedicate to playing, both Wordle and Scrabble can be used to train your brain. Gameplay Wordle asks you to guess a 5 letter word every day. You have 6 guesses to work out what the Wordle word is. It colours the letters green if they are correct, yellow if they are in the Wordle word but not in the right place and grey if they are not. Each puzzle only takes around 2-5 mins. Scrabble requires you to place tiles on a board to create interlinked words. The game can be played with 2-4 players. Each letter is worth a certain number of points, however there are also premium squares that will increase your score. A normal game can take anywhere from 45 mins to over an hour and requires knowledge of short words, scoring and tile management. Cognitive Skills Used Working Memory Both games require working memory to play. Wordle uses working memory as you need to keep track of which letters you have already ruled out, which letters are in the correct place and what the potential shape of the word could be. Whereas Scrabble requires you to keep track of your tiles, premium squares still available, your opponents tile tendencies and your own 7 tile rack. Therefore Scrabble requires more working memory. Deductive Reasoning Wordle requires you to use deductive reasoning. Every guess you make is a hypothesis and the coloured responses are your data. You then use elimination to work out the answer. This is very similar to the scientific method. Whereas Scrabble requires less deductive reasoning as you need to know obscure words to win. Vocabulary In competitive Scrabble players will learn thousands of obscure words. They do not need to know what they mean, just that they are valid words to play for points. Whereas Wordle uses common vocabulary so you will become familiar with high frequency vocabulary. If you are looking to improve your vocabulary Wordle would be more practical. If you are looking to improve your word knowledge Scrabble provides a wider range. Strategic Thinking Scrabble requires you to think ahead. A good player may play a low scoring word to stop your opponent getting access to a triple word square. Or to set up a high scoring word next turn. Strategic thinking is a high level cognitive skill. Wordle does not require strategic thinking as everything happens within 6 guesses. Time Wordle only takes less than 5 minutes to play as it is a daily game. Whereas Scrabble requires more time to play and someone willing to play against you. If you are busy Wordle will be easier to fit into your day. Whereas if you want a more in depth game, Scrabble will provide more engagement. Social Wordle has created a worldwide daily habit with the use of the emoji grid. Millions of people post their results in the same way without giving away the answer. Whereas Scrabble is more competitive and needs to be played with someone. Which is best for training your brain? Neither game is objectively better. wordleunlimited.dev helps you with deductive reasoning, constraint satisfaction and working memory. Whereas Scrabble will help with vocabulary, strategic thinking and concentration. Most people would find it more beneficial to play both games. Playing Wordle as a daily game and Scrabble once a week.

MCPサーバーが利用できません NXPのAgentic AI Development - NXP Communityのドキュメントを参考に、NXPのMCPサービスをVS Codeにインポートしようとしていますが、インポート後に動作しません。ログには「ツールが0個検出されました」と表示されます。これが動作しない原因でしょうか？もしそうなら、解決策を教えてください。

S32K312 FlexCAN – AEN有効化時のTXメッセージバッファアボートとRTD 7.0.1を使用したバスオフリカバリ NXPチームの皆様、こんにちは。 私はS32K3 RTD 7.0.1(AUTOSAR 4.9.0)を用いてNXP S32K312評価ボードを操作しています。RTD API FlexCAN_Ip_Send()およびFlexCAN_Ip_AbortTransfer()を使ってFlexCANのメッセージバッファ中止送信機能をテストしています 。 私のテストでは、中止機能が期待どおりに動作していません。参考資料として、プロジェクトファイル、MEX設定ファイル、およびテストコードを添付しました。 以下の3点について、ご指導いただければ幸いです。 1. 複数の送信メッセージバッファの中止 最初のテストでは、複数のメッセージバッファを使用してメッセージを送信し、その後、それらすべてのバッファに対して中止要求を発行します。テストコードは以下のとおりです。 /* Transmit messages using MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_Send( INST_FLEXCAN_0, lMb_u8, &tx_info, 0x123U, &dummyData[0] ); } /* Request abort for MB0 to MB39. */ for (uint8_t lMb_u8 = 0U; lMb_u8 < 40U; lMb_u8++) { FlexCAN_Ip_AbortTransfer( INST_FLEXCAN_0, lMb_u8 ); } すべての送信要求は同じCAN ID 0x123を使用しますが、メッセージバッファのインデックスは0から39まで変動します。 MCR [AEN]ビットは1に設定されており、アボートメカニズムが有効になっています。しかし、メッセージバッファに対してアボート要求を発行しているにもかかわらず、PCAN-Viewにはすべてのメッセージが表示されてしまいます。 私の予想では、送信がまだ保留中のメッセージは中止されるべきであり、すでに送信が完了したメッセージは中止できないはずです。 以下の点を明確にしていただけますか? 複数のメッセージバッファで送信を行い、その後保留中の送信をすべて中止する場合、推奨される手順はありますか？ 2. 単一のメッセージバッファを使用して送信を中止する 問題を切り分けるために、メッセージバッファ8のみを使用する2つ目のテストを作成しました。 順序は次のとおりです。 MB8の場合はFlexCAN_Ip_Send()を呼び出してください。 FlexCAN_Ip_GetTransferStatus()を使用して転送ステータスを確認します。 送信が成功し、転送ステータスがFLEXCAN_STATUS_BUSYの場合は、 MB8 に対してFlexCAN_Ip_AbortTransfer()を呼び出します。 転送ステータスを再度読み取り、ハードウェアレジスタを検査してください。 送信APIはFLEXCAN_STATUS_SUCCESSを返し、中止前のステータスチェックではFLEXCAN_STATUS_BUSYが報告されます。しかし、中止APIはFLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS （ 0x5 ）を返します。 RTD実装のデバッグ中に、戻りステータスがFlexCAN_AbortTxTransfer()内の以下の条件から発生していることがわかりました。 FlexcanMbConfig = *FlexcanMb; /* Check if the MBs have been safely inactivated */ if ((uint32)FLEXCAN_TX_INACTIVE == ((FlexcanMbConfig & FLEXCAN_IP_CS_CODE_MASK) >> FLEXCAN_IP_CS_CODE_SHIFT)) { /* Transmission has occurred */ Result = FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS; } 現在の構成では、メッセージバッファはメモリブラウザーの0x40304100にあります。中止要求後、 CODEフィールドには、期待される中止コード0x9ではなく、非アクティブ/送信済み状態に対応する0x8が表示されます。 また、 FlexCAN_AbortTxTransfer()内の次のステートメントにブレークポイントを設定しました。 TimeStart = OsIf_GetCounter( FLEXCAN_IP_SERVICE_TIMEOUT_TYPE ); この時点で、 IFLAG1[8]が設定されます。 現在のRTD実装では、アボートシーケンスはメッセージバッファのCODEフィールドにFLEXCAN_TX_ABORT （ 0x9 ）を書き込み、対応するメッセージバッファの割り込みフラグをポーリングします。フラグは、アボートヘルパーが戻った後、FlexCAN_Ip_AbortTransfer()内のFlexCAN_ClearMsgBuffIntStatusFlag( )によってクリアされます。 私が懸念しているのは、中止要求が発行される前に、既に完了した送信によって割り込みフラグが設定されている可能性があることです。もしそうであれば、ポーリングループは新たな中止完了イベントを待つことなく即座に終了できます。しかし、これが私の問題の原因であるかどうかはまだ確認できていません。 3. 自動復旧が無効になっている場合のバスオフ復旧 別のテストでは、自動バスオフリカバリーを無効にし、アプリケーションでリカバリーを処理しようとしています。 バスオフ条件が発生した場合、現在の方法はFlexCANドライバを初期化解除し再初期化することです。しかし、このシーケンスの後、その後のFlexCAN_Ip_Send()呼び出しはメッセージを送信できません。 自動バスオフ回復が無効化された場合の推奨回収手順についてアドバイスいただけますか? 具体的には： 初期化解除と再初期化だけで、FlexCANコントローラをバスオフから復元できますか? 初期化解除前に、未処理のTXメッセージバッファをすべて中止または明示的にクリアする必要がありますか？ 再初期化後、送信前にメッセージバッファを再度設定または初期化する必要がありますか？ コントローラが再び送信する前に、ESR1ステータス、MCR、CTRL1[BOFFREC]、割り込みフラグ、またはRTD内部転送状態に関わる必要な手順はありますか? バスオフ状態からの復旧において、古いTX転送やメールボックスの状態が後続の送信を妨げないようにするための推奨手順は何ですか？ テストプロジェクト、MEXの設定、関連するソースコードを添付して、設定やAPIの使用状況を確認しています。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 こんにちは@Yogs あなたの3つの質問に対する回答を以下にまとめました。 （内容がかなり多く、フォーマットも少し乱雑です。） Q1。「フレックスカン・アボート」に関する質問について。 まず、FlexCANのアボートメカニズムは、保留状態にあるTXメッセージバッファ（MB）に対してのみ有効であることを理解する必要があります。 最初のテストについて： MB0が最初に起動されます。 FlexCANはスキャンを開始し、MB0の内容を送信します。 一方、CPUはMB1、MB2、…、MB39の構成を続行します。 CPUが最終的に2回目のループに到達する頃には、最初のMB群はすでに送信を完了している可能性が高い。 低バス負荷、ACK受信の成功、そしてクラシックCAN特有の8バイトペイロードなどの条件下では、 40フレームの送信は非常に速く完了できます。 2回目のテストについても同様で、バスがアイドル状態であれば、FlexCANはすでに送信を完了している可能性があります。 CPUが中止コマンドを実行する前に。 したがって、あなたの2つのテストはいずれも何も証明していません。 中止操作を適切に検証するには、CPUの実行速度に頼るのではなく、意図的に明確な「保留」期間を作成する必要があります。 例： 別のCANノードに、より優先度の高いIDでバスを継続的に占有するように設定し、ターゲットメッセージバッファ(MB)を保留状態に保ち、その後アボートをトリガーします。 Q2: なぜシングルMBテストは最初はBUSYで返却されるのに、中止リクエスト時にNO_TRANSFER_IN_PROGRESS戻るのでしょうか? 両者の間で短時間の状態不一致が生じることがあります: 「FlexCAN_Ip_Send()」はRTD(ランタイムドライバー)の状態を「BUSY」に設定します。 ハードウェアが送信を開始します。 フレームの送信が完了すると、ハードウェアはMB（メッセージバッファ）CODEを`0x8`に更新し、`IFLAG`を設定します。 TX IRQ ハンドラがまだ実行されていない場合、またはブレークポイント デバッグ中にシステムが一時停止されている場合、RTD 状態構造は `BUSY` のままになる可能性があります。 この時点で「中止」操作が呼び出されます。 内部的には、`Abort`関数はMB CODEを読み取り、それが既に`0x8`であることを確認します。 `FLEXCAN_STATUS_NO_TRANSFER_IN_PROGRESS` を返します。 したがって、`GetTransferStatus() = BUSY` かつ `FlexCAN_Ip_AbortTransfer() = NO_TRANSFER_IN_PROGRESS` となります。 それらは必ずしも矛盾するものではない。 前者はソフトウェアの簿記を反映している場合があり、後者は実際のハードウェアコードを確認するものです。 Q3。バス離脱回収 CANモジュールを再初期化することで「バスオフ」状態から回復することは十分に可能です。 手動で「バスオフ」復旧を行うには、アプリケーション層がまずデータ伝送を停止し、保留中の送信(TX)リクエストをすべてキャンセルまたは破棄しなければなりません(中止)。 その後、コントローラは完全な初期化解除と再初期化を受けなければなりません。 その後、アプリケーション層受信(RX)メッセージバッファ(MB)を再構成し、古いメッセージバッファフラグ、エラーフラグ、ソフトウェア伝送状態をクリアする必要があります。 送信を再開する前に、アプリケーション層はコントローラが「フリーズ」または「準備不足」状態を解除したことを確認し、送信メッセージバッファ(TX MB)や「送信準備完了」(RTD)の状態が「混雑」状態に残っていないことを確認する必要があります。 テストが失敗したとおっしゃっていたので、おそらく上記の手順を見落としていたのでしょう。添付ファイルにはバス離脱の復旧手順に関する情報は見つかりませんでした。まだ疑問があれば、テストプロジェクトを私に共有してください。確認のために確認します。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 Q1について、私の試験条件を明確にしたいと思います。 CANボーレート は 500 kbps で 、8バイトのペイロードを持つクラシックCANフレームはバス 上で約 300μs の送信時間を要します。 私のテストでは、まずそれぞれのTXメッセージバッファを通してメッセージを送信し、その後すぐに中止関数を実行します。中止関数は対応するメッセージバッファを順に処理し、それぞれのバッファに対してFlexCAN_AbortTxTransfer()を呼び出します。 したがって、アボート要求は送信リクエストの直後にそれぞれのメッセージバッファに対して発行されており、意図的に遅延しているわけではありません。 最初の数通のメッセージは、中止ループが到達する前に送信が完了している可能性があることを理解しています。しかし、おおよその送信時間と送信されたメッセージ数を考慮すると、後続のメッセージバッファの一部は、中止要求が発行された時点でまだ送信待ちの状態になっていると予想されます。 保留中のメッセージが中止されるのを防ぐ他のハードウェア条件やタイミング要因があるのか、教えていただけますか? Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 こんにちは@Yogs これは、コード内の「abort MB」のデフォルトのシーケンスです。 for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,lMb_u8); } 「40 - 1Mb_u8」に変更しました。 for(uint8_t lMb_u8 = 0; lMb_u8 < 40; lMb_u8++) { FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0,40 - lMb_u8); } 以下は私のテスト結果です。 受信したデータは2フレームのみで、その他のMBはすべて正常に中断されました。 この検証結果は、私が以前立てた仮説を裏付けるのに十分です。つまり、あなたが「MBの中止」操作を実行する前に、現在のMBは既に正常に送信されていたということです。 Re: S32K312 FlexCAN – TX Message Buffer Abort with AEN Enabled and Bus-Off Recovery Using RTD 7.0.1 こんにちは、 ご説明ありがとうございます。ご指摘の内容を理解し、逆順の中止シーケンスをテストしました。ご指摘のとおり、この方法の方がうまくいきます。バス上で受信するフレームは2つだけで、残りのメッセージは正常に破棄されます。 しかし、その行動に関していくつか疑問があります。 1. なぜ逆順中絶が必要なのですか？ この2つのループは、実行順序が異なるだけで、本質的には同じ操作を実行しているのではないでしょうか？ なぜ最も高い郵便受けインデックスから中止を開始することがこれほど大きな違いを生むのか説明してもらえますか?これは、FlexCANが内部的にTXメッセージバッファをスキャンまたは選択する順序に関係していますか？ 逆順の中止処理はハードウェア要件ですか、それとも保留中のメッセージを中止する確率を高めるための推奨手法に過ぎませんか？ 2. 単一のメッセージバッファを中止する場合はどうでしょうか？ また、メッセージバッファを1つだけ使用して、中止機能のテストも行いました。 FlexCAN_Ip_Send( INST_FLEXCAN_0、 0U、 &tx_info、 0x123U、 &dummyData[0] ); FlexCAN_Ip_AbortTransfer(INST_FLEXCAN_0, 0U); FlexCAN_Ip_Send() の実行から FlexCAN_Ip_AbortTransfer() の呼び出しまでの時間をベンチマークしました。所要時間は約10.3マイクロ秒です。 しかし、この短い間隔でもメッセージはCANバス上で送信されます。 PCAN-Viewからの優先度の高いメッセージを使用してバス負荷を適度に維持しましたが、単一メッセージによるアボートは依然として成功しません。 比較のために、複数のメッセージバッファを使用して送信し、その後逆順にそれらを中止した場合、シーケンスの測定時間は約9.3ミリ秒であり、残りのメッセージは中止される一方で、バス上で受信されるフレームは2つだけです。 これは別の疑問を提起します。送信APIが応答を返してから約10.3マイクロ秒後に中止要求が発行された場合でも、単一メッセージの中止は失敗するのに対し、複数メールボックスの逆順アプローチではほとんどのメッセージが正常に中止されるのはなぜでしょうか？ アボートリクエストが発行される前に、単一のメッセージがすでに内部のTXシリアルメッセージバッファ(TX SMB)に転送されている可能性はありますか? ハードウェアがこのシナリオをどのように処理するのか、また、単一メッセージバッファのアボートメカニズムを確実にテストする方法について、ご説明いただけると幸いです。

IW610 – BLE Coded PHYのパッシブスキャンで、アドバタイジングレポートの受信がランダムに停止する こんにちは、 私たちは、NXP IW610(Quectel FGA66X、USBバリアント)をベースにしたデバイスを開発し ており、ホストプロセッサはSunplus SP7021でLinuxカーネル5.10を搭載しています。 コード 化されたPHYでのBLEパッシブスキャンがランダムに広告報告の受信を停止 する 問題 が発生しています 。問題は断続的で、スキャンは1時間で停止することもあれば、24時間以上中断せずに動作し続けることがあります。 Quectelが提供するファームウェア/ドライバーパッケージ(18.99.8.p3)と、NXP GitHubで入手可能な新しいバージョン(18.99.8.p136)の両方をテストしました。複数のドライバーパラメータ設定も試しましたが、問題は解決しませんでした。 以下のHCIコマンドを使用して、Coded PHY上でパッシブ拡張スキャンを設定および有効化します。 # LE Set Extended Scan Parameters hcitool cmd 0x08 0x0041 0x00 0x00 0x04 0x00 0x10 0x00 0x10 0x00 # LE Set Extended Scan Enable hcitool cmd 0x08 0x0042 0x01 0x00 0x00 0x00 0x00 0x00 一定時間経過後、モジュールはHCI経由で受信したBLEアドバタイジングパケットの報告を停止します。hciconfigはモジュールが稼働中であると報告します。 mbt_drvdbg=0xFFも有効にしましたが、スキャンが停止する原因を示すものは何も見つかりませんでした。カーネルログには、明らかなクラッシュ、ファームウェアの障害、またはエラーメッセージは記録されていません。 スキャンは上記の2つのHCIコマンドを再度発行することで復元できます。 Bluetoothモジュールをリセットしたり、再起動したりする必要はありません。スキャンを再度有効にすると、正常に動作するようになりますが、それもまた予測不可能な期間だけです。 そこで質問があります: これはIW610のファームウェアやBluetoothドライバの既知の問題でしょうか? Coded PHYにおけるパッシブスキャンに関して、既知の制限事項や特定の構成要件はありますか？ 原因を特定するために他に有効化や記録できることはありますか?他に試してみる価値のあるファームウェアやドライバのデバッグオプションはありますか? 定期的にスキャンを無効化・有効化する以外に、既知の回避策はありますか？ 何かご提案やアドバイスがあれば、ぜひお聞かせください。 よろしくお願いします。 Re: IW610 – BLE Coded PHY passive scanning randomly stops receiving advertising reports あなたが見ている症状はIW610で既知の問題クラスのように見えます。コードドPHY拡張スキャン状態機械は静かに停止する一方で、コントローラは依然としてUPを報告します。2つのHCIコマンドを再発行すると必ず復元し、Quectelの18.99.8.p3とNXP p136のファームウェアの両方で同じ現象が起きていることは、ホスト側の問題ではなくファームウェアやドライバのバグを示しています。 以下に、最も効果的な次のステップを示します。 1. **より安全なスキャンパラメータセットを試してください** 現在のコマンドでは、ScanInterval=ScanWindow=0x0010 (10 ms) が使用されており、実質的に Coded PHY 上で連続スキャンが行われています。それでRXスケジューラーが動くことがあります。もう少し穏やかなウィンドウ設定を試してみてください。例： 「`」 hcitool cmd 0x08 0x0041 0x00 0x00 0x04 0x00 0x40 0x00 0x20 0x00 「`」 可能であれば、Phys=0x05 (1M + Coded) もテストして、純粋な Coded PHY の場合にのみストールが発生するかどうかを確認してください。 2. **停止が発生した際に適切なログを取得する** 詳細な動的デバッグを有効にする： 「`」 echo 'ファイル hci_core.c+p' > /sys/kernel/debug/dynamic_debug/control echo 'ファイル hci_event.c+p' > /sys/kernel/debug/dynamic_debug/control echo 'ファイル btusb.c+p' > /sys/kernel/debug/usb/btusb/control echo 'ファイル mbt*.c+p' > /sys/kernel/debug/dynamic_debug/control 「`」 `hcidump -i hci0 -w scan.log` と `btmon -w btmon.log` を並行して実行します。スキャンが停止したら、すぐに以下を確認してください: - サイレンス前の最後のHCIイベント情報(LE広告セット終了、LEスキャンタイムアウト、ハードウェアエラー、コマンド無効を参照)。 - ホストがまだACL/ISOトラフィックを送信しているかどうか。 - USB URB の状態 (`dmesg | grep -i usb` および `cat /sys/kernel/debug/usb/devices`)。 また、RSSI、温度、USBバス負荷も収集してください。もし停止が温度やバスの混雑と相関している場合は、別の根本原因を示唆しています。 3. **一時的な対策としての監視スクリプト** 復旧とは単にスキャンを再度有効にするだけなので、ユーザー空間にウォッチドッグを配置するのが現状では最も信頼性の高い回避策です。最小限の論理： ```bash #!/bin/bash LOG=/tmp/bt_scan_watch.log 真である間; # 過去30秒以内に広告レポートを受信したかどうかを確認します if ! hciconfig hci0 leadv 2>/dev/null | grep -q "LE Scan"; then echo "$(date) - スキャンが停止しました。復旧中です" >> $LOG hcitool cmd 0x08 0x0042 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 1日間眠る hcitool cmd 0x08 0x0041 0x00 0x00 0x04 0x00 0x40 0x00 0x20 0x00 hcitool cmd 0x08 0x0042 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 フィ 30分眠る 終わり 「`」 これによりコントローラの完全なリセットを避け、USBやファームウェアの状態をデバッグのために保持できます。 4. **NXP/Quectelに提供すべき情報** 公式な修正プログラムが必要な場合は、最小限の再現可能な環境を準備してください。 - 1つのデバイスがCoded PHY拡張アドバタイズメントを継続的に送信する。 - IW610はパッシブ拡張スキャンのみで動作します（接続なし、Wi-Fiトラフィックなし）。 - 停止した瞬間を捉えたhcidump、btmon、dmesg、およびUSBトレースのログ。 ファームウェアのバージョンと正確なHCIコマンドシーケンス。 18.99.8.p3と18.99.8.p136はどちらも同じ動作を示し、スキャン無効化/有効化のペアを再発行することによってのみ復旧できることを述べてください。 5. **追加のファームウェアデバッグオプション** 「mbt_drvdbg=0xFF」を超えて、ドライバがBLEのRXパス用に「drvdbg」マスクを公開しているか確認してください(例:スキャン用に「0x10」、PHYスイッチング用に「0x20」を表示)。モジュールがサポートしている場合、UARTやUSBベンダーコマンドでコントローラ側のログを有効にすることで、ホストHCI層が認識できない内部の状態機械遷移を明らかにできます。 現時点で、NXPはリリースされたファームウェアパッケージ内でIW610の特定のコード化されたPHYスキャンストール修正を公に文書化していません。もし失速前の最後のHCIイベント情報を示すトレースをキャプチャできれば、それがNXPのエンジニアリングチームにとって最も強力な手がかりになります。

BCC MC33771C 测量时序 各位同事好，   我们正在使用 MC33771C 电池单元控制器 (BCC)，并观察到使用不同的读取间隔时电压/温度测量读取时间存在差异。   测试观察结果：   配置：与 BCC 配置相同，有 4 个从节点。 读取间隔：10 毫秒：从所有 4 个从站读取温度数据大约需要 40 毫秒。 读取间隔：100 毫秒：从所有 4 个从站读取相同的温度数据大约需要 7.7 毫秒。 我们观察到，即使配置保持不变，当读取间隔设置为 10 毫秒时，总测量读取时间也会明显增加。   请问您能否帮我们理解以下问题？   为什么 10 毫秒和 100 毫秒读取间隔的测量读取时间会有显著差异？ 读取间隔与ADC转换、测量更新或BCC通信时序之间是否存在任何依赖关系？ 使用 4 个 BCC 从设备时，是否有推荐的配置或步骤来实现一致且优化的电压/温度读取时序？ 从多个 MC33771C 设备读取测量数据时，我们是否需要考虑任何特定的时间限制或同步要求？ 如需进一步分析，如需其他配置详情或测量日志，请与我们联系。 Re: BCC MC33771C measurement timing 你好，Nirmal， 感谢您确认ADC配置。这是一个重要的澄清：当 ADC_CFG[AVG] = 0 且分辨率为 16 位时，硬件 tEOC 仅为 ~520 µs。您在 10 毫秒间隔内观察到的 40 毫秒读取时间不可能是 ADC 转换本身造成的，几乎可以肯定是由固件测量序列造成的。 tEOC ≈ 520 µs，因此在两个时间间隔到期之前，数据就已经准备就绪。因此，观察到的读取时间差异源于固件触发信号 SOC 并读取结果相对于该时间间隔的方式和时间。导致这种特定症状的最常见原因是： 1. SYS_CFG1[CYCLIC_TIMER] 在 10 毫秒时激活 如果循环定时器设置为 10 毫秒，则设备每 10 毫秒自动触发信号一次循环转换。但是，循环转换不会更新 MEAS_xxxx 测量寄存器——它们只会更新 OV/UV/OT/UT 故障标志。如果 MCU 固件在发出在线点播 SOC 之前等待循环触发信号，则有效测量周期将与循环周期耦合，每次读取之前最多会增加 10 毫秒的延迟。在 100 毫秒的循环周期下，这种延迟消失了，因为 MCU 可以独立地在线点播发出 SOC。请验证 SYS_CFG1[CYCLIC_TIMER] 的值，如果已激活，请考虑禁用它或将 MCU 读取序列与其完全解耦。 2. 读取前插入固定时间间隔延迟（不等待 EOC） 如果固件发出 SOC 信号，然后等待完整的读取间隔（10 毫秒或 100 毫秒）后再进行读取，而不是轮询 EOC 标志，则其行为将是： 100 毫秒：SOC → 等待 100 毫秒 → 读取（通信时间 7.7 毫秒）→ 测量值 ≈ 7.7 毫秒 ✓ 10 毫秒：SOC → 等待 10 毫秒 → 读取（7.7 毫秒通信） → 但是如果循环重复且时间累积，则有效测量持续时间会增加。 3. SOC 是按从设备发放的，而不是广播发放的。 如果固件分别向每个从设备触发信号 SOC，并强制执行每次读取之间的间隔，则 4 个从设备的总和将是间隔的倍数。 4个奴隶的正确顺序是： - 同时向所有 4 个从设备发出单个广播 SOC。 - 轮询 EOC 标志（或在 16 位时等待至少 520 µs，AVG=0）— 不要使用等于读取间隔的固定延迟。 - 确认 EOC 后，依次读取所有 4 个从属设备。 BRs，托马斯 按您所需的时间间隔重复。 Re: BCC MC33771C measurement timing 你好@TomasVaverka 感谢您的详细解释。 在我们的配置中，我们使用以下设置： ADC_CFG[AVG] = 0 ADC分辨率 = 16位 BCC 从节点数量 = 4 我们对两个测试用例使用了相同的配置（读取间隔分别为 10 毫秒和 100 毫秒）。 但是，我们观察到以下时间差异： 10 毫秒读取间隔：从所有 4 个从站读取温度数据大约需要 40 毫秒。 100 毫秒读取间隔：从所有 4 个从站读取温度数据大约需要 7.7 毫秒。 由于两种情况下 ADC 平均值和分辨率设置相同，请问为什么转换和测量读出时间会有如此大的差异？ 是否存在与 SOC 触发信号间隔、ADC 转换状态或 EOC 标志处理相关的依赖关系，可以解释这种行为？ 您能否也建议一下，如何在 10 毫秒的测量间隔下实现一致的测量读数时间？ Re: BCC MC33771C measurement timing 你好，Nirmal， 时间差异很可能是由您的 ADC_CFG[AVG] 平均设置引起的。 启用平均值后，tEOC（从 SOC 到数据准备就绪的时间）与样本计数成正比。例如，在 16 位分辨率且 AVG=64 的情况下，tEOC ≈ 32.5 毫秒 — 远远超过您的 10 毫秒读取间隔。这就解释了观察到的现象： 每隔 100 毫秒：当 MCU 读取时转换已经完成 → 仅测量通信时间（~7.7 毫秒）。 每隔 10 毫秒：MCU 必须等待转换完成 → 测量时间 = 剩余的 tEOC 等待时间 + 通信时间 ≈ 40 毫秒。 以下几点与您的问题相关： 1. 循环模式 (SYS_CFG1[CYCLIC_TIMER]) 不会更新 MEAS_xxxx 寄存器 — 它只会更新故障标志 (OV/UV/OT/UT)。要获得实际的电压/温度读数，需要在线点播 SOC 信息。循环模式下也不支持平均值计算。 2. 务必等待 EOC 标志出现后再读取结果。除非能保证延迟时间超过 tEOC，否则不要使用等于读取间隔的固定延迟时间。 3. 对于 4 个从设备：同时向所有从设备广播一个 SOC（所有设备并行转换，在 tEOC 完成），然后按顺序读取。在 16 位，AVG=0 时，最小总时间约为 0.52 毫秒 (tEOC) + 4 × 0.7 毫秒 (TPL 通信) ≈ 3.3 毫秒。 4. 有关完整的时序优化框架，请参阅 AN12637：基于 MC33771C 和 MC33772C 的系统时序优化（可在 nxp.com 上获取，需要登录）。 BRs，托马斯 Re: BCC MC33771C measurement timing 你好@TomasVaverka ， 我使用广播消息进行 SoC 通信，但仍然遇到时序差异问题。

overtemperature hi  i want to know if the S32K32 has the internal temperature sensor to monitor the self chip temperature? Assume the S32K32 has the internal temperature sensor how to set and process for the software? tanks. Re: overtemperature Hi @qiaoqin_wang  Yes. Please refer to Example S32K344 TempSenser S32DS36 RTD600/500/400_p24 Best Regards, Robin

RW612 的 32.768kHz 晶体 你好， 我目前正在进行一个PCB设计项目，其中包括来自u-blox的IRIS-W10模块，该模块内部有一个RW612芯片。这是我第一个使用恩智浦MCU的设计。 我不太确定应该如何设计RTC外部晶振的电路。根据其他MCU（例如STM32）的经验，我知道它们需要在晶振的两个引脚上都连接一个外部负载电容。但对于 NXP MCU 来说，似乎有些型号具有内部可配置的负载电容。在 RW612 寄存器列表中，我偶然发现了 RTC CTRL 寄存器，特别是字段 RTC_OSC_LOADCAP。在我看来，这表明该 MCU 实际上具有内部负载电容，但我找不到任何关于此领域的文档。 所以我的问题是：要在该寄存器中设置一个特定的电容值，位格式是什么？ 产品：WiFi RW6XX Re: 32.768kHz Crystal for RW612 以下是 32k 晶振的相关寄存器。RTC_OSC_LOADCAP 寄存器看起来很神秘，因为它可能不适用于此产品。 Re: 32.768kHz Crystal for RW612 感谢您的回复。 RTC晶体的结构似乎分为两个部分。你给我看的那个是PMU的。让我头疼的是RTC部分。 从下面的屏幕截图中可以看到，没有外部电容，但我也没有看到任何内部电容。 在这张截图中，你可以看到我在问题中提到的那个具体的寄存器。 你说的可能是对的，这个 MCU 根本没有内部电容，但如果是这样，RTC_OSC_LOADCAP 字段在寄存器文档中就不应该可见。 另一方面，FRDM-RW612 的这款晶体电路出厂时没有负载电容。 Re: 32.768kHz Crystal for RW612 嗨@Niwo ，希望你一切都好。 请问您是否已经选定了32kHz的晶体？这一点很重要，因为每个晶体都需要其数据手册中定义的特定负载电容。 此外，强烈建议与晶体制造商合作，确定晶体电路周围的合适特性。 Re: 32.768kHz Crystal for RW612 你好@RomanVR ， 感谢您的反馈， 我还没订购任何零件，但我打算用这个： https://eu.mouser.com/de/ProductDetail/ECS/ECS-.327-6-16-TR3?qs=A6eO %2BMLsxmSq6P7XbVvfvw% 3D%3D 顺祝商祺！ Re: 32.768kHz Crystal for RW612 @Niwo你好，很抱歉回复晚了。 根据共享的晶体数据手册，所需的负载电容为 12pF，因此应以此作为配置任何外部电路的指导，并与晶体制造商进一步分析以获得最佳性能建议。 关于上述寄存器，它不应用于配置外部晶体负载电容，这一意见已提交给相关团队采取进一步行动。对于 XTAL32K 功能和晶体相关要求，UM11865 的第 10 章是正确的参考资料。 希望这能帮到你！ Re: 32.768kHz Crystal for RW612 你好@RomanVR ， 我想对文档提出一些修改建议，我认为这将使其他人更容易理解 32.768kHz 晶体的设计： 从 RM00278 和 MCUXpressoSDK 驱动程序中移除 RTC CTRL 寄存器中的 RTC_OSC_LOADCAP 字段 在 UM11865 的图 71 中添加外部负载电容，或者更好的是，在第 10 章中添加一个原理图，显示晶体和负载电容连接到 GPIO[22] 和 GPIO[23]。 在 UM11865 的第 10 章第 2 节中，我不明白“外部电容：18 pF”应该告诉读者什么。请详细说明一下。 希望我的反馈对您有所帮助。 顺祝商祺！

S32DS 2018 license 过期 hi： S32 Design Studio for ARM v2018 R1 license 过期，麻烦帮忙处理一下，谢谢！ Re: S32DS 2018 license 过期 Hi,  your S32DS license has been extended.  回复： S32DS 2018 license 过期 hi： S32 Design Studio for ARM v2018 R1 license 过期，麻烦帮忙处理一下，谢谢！ @jiri_kral 

Matter Stack 移植到 MIMXRT700-EVK (MIMXRT798S) — 持久存储初始化失败 您好， 我目前正在使用 MCUXpresso SDK 和 VS Code 将 NXP Matter 协议栈移植到 MIMXRT700-EVK (MIMXRT798S)板上。该板使用基于 IW612 芯片组的外部 Murata Type 2EL 无线模块。 开发设置和变更 我通过 VS Code 下载并设置了 Matter MCUXpresso SDK 工作区。该工作区位于matter_mcuxpresso/mcuxsdk 。 我针对RT700进行了以下方面的修改： Matter:修改了中间件/matter下的文件，用于 RT700 平台集成。 无线框架：增加了对外部 Murata Type 2EL (IW612) 无线模块的 RT700 特定平台支持和集成。 链接器脚本：使用 RT700 SDK 提供的MIMXRT798Sxxxx_cm33_core0_flash.ld作为参考，并根据 Matter 应用程序的内存布局和 NVS 存储配置对其进行了修改。 问题描述 Matter 应用程序构建成功，并且可以使用 LinkServer 进行编程。但是，运行时初始化失败，并在src/platform/nxp/common/NXPConfigNVS.cpp中的以下调用处出现CHIP_ERROR_PERSISTED_STORAGE_FAILED错误： flash_init(fa->fa_dev) CHIP_ERROR_PERSISTED_STORAGE_FAILED 链接器脚本附件 我将附上修改后的MIMXRT798Sxxxx_cm33_core0_flash.ld链接器脚本供您参考。该脚本基于 RT700 SDK 提供的链接器脚本，并针对 Matter 应用程序的内存布局和 NVS 存储配置进行了修改。 需要支持 请问您能否帮忙澄清一下： 如何在RT700-EVK上配置Matter持久存储的闪存设备和驱动程序？ 是否还需要任何针对 RT700 的额外闪存驱动程序或 NVS 集成步骤？ 修改后的链接器脚本或 NVS 内存布局是否会导致flash_init()失败？ 我希望您能指导我如何解决这个问题。 谢谢！ 评估板 Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure 嗨@Aparna1 ， 谢谢你的提问！ 我已审核提供的链接脚本。它目前引用了以下与 FlexSPI 相关的对象： *(EXCLUDE_FILE( ... *fsl_adapter_flexspi_nor_flash.c.o* *mflash_drv.c.o* *fsl_flexspi.c.o* ) .text*) 但是，MIMXRT700 使用的是 XSPI 控制器。请确认该应用程序已链接到正确的 RT700 XSPI 闪存后端，并且 fa->fa_dev 指的是该设备，而不是其他 i.MX RT 平台使用的 FlexSPI 后端。 另请检查映射文件中的 flash_init() 、闪存擦除/编程功能以及相关的 XSPI_* 功能。这些功能及其所需的配置数据应该位于 RAM 中，而不是 XIP 闪存区域中。 我们建议按以下顺序检查端口： 验证 SDK 中的官方 RT700 XSPI 或非 闪存示例； 确认 fa->fa_dev 使用正确的XSPI后端； 验证闪存操作代码是否确实从 RAM 中执行； 然后检查 NVS 地址、扇区对齐方式，以及驱动程序是否期望绝对地址或设备相对偏移量。 此致， 加文 Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure 嗨@Gavin_Jia 我已根据建议修改了链接器文件（ MIMXRT798Sxxxx_cm33_core0_flash.ld ），并更新了与 XSPI 相关的配置。但是，问题仍然存在， flash_init()函数仍然失败。 我已将修改后的MIMXRT798Sxxxx_cm33_core0_flash.ld文件分享给您审核。请您检查一下链接器配置，并指导我还需要做哪些更改才能解决 XSPI 闪存初始化问题？ 谢谢！

PCF85263AT/AJ——屏幕上显示的分钟数为任意值。 在代码迁移任务中，我们遇到了 BSF 标志被设置的问题。由于 BSF 标志被设置，分钟寄存器中的 EMON 位也被设置。 因此，屏幕上显示的分钟数是一个任意值。此外，年份值无法正确保存，即使在设置了 RTC 日期和时间之后，年份值仍然持续显示 2000。 我尝试测试了下面提到的条件，但问题仍然存在。 我将标志寄存器（0x43）设置为 0x00 并立即读取它；它显示 0x00。然而，3秒后我再次读取寄存器时，其值又被设置为0x08（或0x00）。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 你好 Ris_eek 再会！ BSF 标志并非只是无法清除。相反，RTC 检测到新的电池切换事件，并再次设置 BSF。根据数据手册，当电池切换逻辑检测到电源转换事件时，BSF 将被设置。 它在大约 3 秒后重新确立的事实意味着 VDD 电源反复降至电池切换阈值以下，导致反复出现 VDD>VBAT>VDD 转换。每次转换都会重置 BSF。 RafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.png 这种持续的电压波动导致 RTC 不断 RESET，这就是为什么它只显示 2000 年的原因。我建议检查一下电源信号是否存在问题。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 亲爱的拉法尔； 谢谢你的来信。   在硬件方面，VDD（4.93 VDC）和VBAT（3.02 VDC）电压是恒定的。为防止电压波动，在电池电源两端并联了一个 100 nF 的电容。 电池开关寄存器（26h）设置为 0x00。因此，BSM（电池开关模式）配置为在 Vth 电平进行切换。Vth 电平为 1.5 V，因为 BSTH（电池开关阈值电压）位设置为 0。 如图 25 所示（如前一封邮件中所述）： 当 VDD < Vth 时，BSF 设置为 1。 当 VDD > VBAT 时，BSF 应被清除。 然而，在通电状态下，测得的电压为 VDD = 4.93 VDC，大于 VBAT = 3.02 V。即使如此，边防部队也未能通过清剿。 请问为什么即使 VDD 大于 VBAT，BSF 仍然保持设置状态？ Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 你好 Ris_eek 再会！ 数据手册上写着： 声明标志 BSF（寄存器标志，地址 2Bh）可用于在引脚 INTA 和 INTB 上产生中断。中断可以生成为脉冲信号，也可以生成为持续有效的信号，该信号遵循位 BSF 的条件。BSF 保持设置状态，直至接到命令解除。 我发送的参考图像还显示以下内容：“通过接口清除。” 这不会自动完成，你需要手动清除。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 好的，拉法尔 谢谢。 但是，BSF 标志在软件中被清除，但过一段时间后，它会再次被设置，正如我在之前的帖子中描述的那样。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 谢谢， 现在我的 PCF85263AT/AJ 代码迁移已经完成。我们现在想使用 RTC 中的偏移寄存器来提高时钟精度，并且我们正在将其设置为 OFFM=1（快速模式）。在测试为偏移校正而构建的固件时，我们观察到 DSO 上 INTA(CLK) 引脚信号的频率在 32.68kHz 到 32.80kHz 之间变化。请查看附图。我们的微控制器也读取到了相同的数据。 根据数据手册7.8.3节图20，计算32.68kHz的偏移值： A) 考虑：CLKOUT fmeas = 32680 Hz，因此 Tmeas = 30.599755 微秒 B) Dmeas = 30.517578 usec - 30.599755 usec = -0.082176微秒 C) Eppm = 10^6 x (-0.082176/30.599755)= -2685.51169 ppm D) 偏移值（当 OFFM=1 时，即快速模式）= -2685.51169/2.0345= -1319.98 ≈ -1320 根据表格编号。24 在数据手册的 7.8 节中，演示仅显示了 -127 到 +128 的十进制偏移值。但就我们目前的情况而言，当计算出的值为 -1320 时，我们无法理解应该向 OFFSET[7:0] 寄存器写入什么值。因此，我们不确定如何在应用程序代码中编写或编写什么内容来测试偏移校准。请指导我们下一步该怎么做。

s32k2018.R1没办法延期 麻烦帮我给这个激活码延下期，谢谢。 Activation Code D870-0066-E5E6-ACC7

S32 デザインスタジオのライセンスが切れました こんにちは、 私のS32デザインスタジオライセンスはもうすぐ期限切れになります。 免許の更新は可能ですか? ライセンスコードは085B-C474-AA78-FC99です。 ご回答をお待ちしています。 Re: s32 design studio license expired こんにちは、 お客様のS32DSライセンスが延長されました。 Re: s32 design studio license expired こんにちは、 今あなたのアカウントを確認したところ、ライセンスは2030年まで有効です。ライセンスが本当に期限切れでないまで待つか、既存のライセンスを返却して古いコードで再度有効化することもできます。 Re: s32 design studio license expired こんにちは、 ssong_0-1789444671642.png まだ延長されていないようです。もう一度確認してもらえますか?ありがとう。 Re: s32 design studio license expired こんにちは、NXPサポートの皆さん。このメッセージがあなたの元に無事届くことを願っています。私のS32DSライセンスが期限切れになり、現在の開発作業が妨げられています。延長を手伝ってもらえますか? 私の認証ID： 406C-B408-57DB-0C62 製品:ARM v2.2用のS32 Design Studio。 ご返信よろしくお願いします。

MatterスタックのMIMXRT700-EVK(MIMXRT798S)への移植 — 永続的なストレージ初期化の失敗 こんにちは、 現在、MCUXpresso SDKとVS Codeを使ってNXP MatterスタックをMIMXRT700-EVK(MIMXRT798S)に移植する作業を進めています 。このボードはIW612チップセットをベースにした外付けのMurata Type 2EL無線モジュールを使用しています。 開発環境のセットアップと変更 VS Codeを通じてマター MCUXpresso SDKワークスペースをダウンロードし、セットアップしました。ワークスペースはmatter_mcuxpresso/mcuxsdkにあります。 以下の点において、RT700専用の変更を加えました。 マター:RT700プラットフォーム統合のためにミドルウェア/マター上でファイルを修正しました。 ワイヤレスフレームワーク: 外部村田タイプ2EL(IW612)無線モジュールのRT700専用プラットフォームサポートと統合を追加。 リンカースクリプト:RT700 SDKが提供するMIMXRT798Sxxxx_cm33_core0_flash.ldを参照として使用し、MatterアプリケーションのメモリレイアウトおよびNVSストレージ構成に合わせて修正しました。 問題の説明 Matterアプリケーションは正常にビルドでき、LinkServerを使ってプログラム可能です。しかし、src/platform/nxp/common/NXPConfigNVS.cppの以下の呼び出しでCHIP_ERROR_PERSISTED_STORAGE_FAILEDが実行されると実行時の初期化が失敗します。 flash_init(fa->fa_dev) CHIP_ERROR_PERSISTED_STORAGE_FAILED リンカースクリプトの添付ファイル 参照のために修正されたMIMXRT798Sxxxx_cm33_core0_flash.ldリンカースクリプトを添付します 。これはRT700 SDKが提供するリンカースクリプトを基にしており、MatterアプリケーションのメモリレイアウトおよびNVSストレージ構成の変更を含んでいます。 サポートが必要です もう少し詳しく教えていただけますか: RT700-EVKのマター永続保存ストレージ用にフラッシュデバイスとドライバーはどのように設定すべきでしょうか? RT700専用のフラッシュドライバーやNVS統合の追加ステップは必要ですか? 修正されたリンカースクリプトやNVSメモリレイアウトがflash_init()の失敗に影響している可能性はありますか? この問題の解決について、ご指導いただければ幸いです。 よろしくお願いします。 評価ボード Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、@Aparna1 さん。 ご質問ありがとうございます！ 提供されたリンカースクリプトを確認しました。現在、以下のFlexSPI関連オブジェクトを参照しています。 *(EXCLUDE_FILE( ... *fsl_adapter_flexspi_nor_flash.c.o* *mflash_drv.c.o* *fsl_flexspi.c.o* ) .text*) ただし、MIMXRT700はXSPIコントローラを使用しています。アプリケーションが正しいRT700 XSPIフラッシュバックエンドとリンクされており、他のRTプラットフォームで使われるFlexSPIバックエンドではなく、このデバイスを指している i.MX fa->fa_dev 確認してください。 また、マップファイルで flash_init() 、フラッシュ消去/プログラム機能、および関連する XSPI_* 機能を確認してください。これらの機能およびそれらに必要な設定データは、XIPフラッシュ領域ではなく、RAMに配置する必要があります。 ポートの確認は以下の順序で行うことをお勧めします。 SDKの公式RT700 XSPI NORフラッシュ例を確認してください。 fa->fa_dev 正しいXSPIバックエンドを使用していることを確認してください。 フラッシュ操作コードが実際にRAMから実行されることを確認する。 次にNVSアドレス、セクターアライメント、ドライバが絶対アドレスかデバイス相対オフセットを期待しているかを確認します。 よろしくお願いします、 ギャビン Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、 @Gavin_Jia ご提案いただいた変更に基づいてリンカーファイル（ MIMXRT798Sxxxx_cm33_core0_flash.ld ）を修正し、XSPI関連の設定を更新しました。しかし、問題は依然として解決せず、 flash_init()関数が引き続き失敗します。 修正済みのMIMXRT798Sxxxx_cm33_core0_flash.ldファイルを共有してご覧いただきます。リンク設定を確認し、XSPIフラッシュの初期化問題を解決するために追加で何の変更が必要か教えていただけませんか? よろしくお願いします。

过温 hi 我想知道S32K32是否有内置温度传感器来监测芯片自身温度？ 假设S32K32带有内部温度传感器，软件该如何设置和处理？ 坦克。 Re: overtemperature 嗨@qiaoqin_wang 是的。 请参考示例 S32K344 温度传感器 S32DS36 RTD600/500/400_p24 此致敬礼， Robin

The s32k2018.R1 cannot be postponed. Could you please extend this activation code for the next period? Thank you. Activation Code D870-0066-E5E6-ACC7

Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, My name is Eunjin Kwon, and I am a researcher in the Eco-Friendly Building Research Team at GS Engineering & Construction in South Korea. We are currently exploring the application of mmWave radar technology for non-contact fall detection and activity monitoring in residential environments. One of our key technical requirements is to distinguish humans from pets (such as dogs and cats) to prevent false alarms caused by pet movements while ensuring reliable fall detection for human occupants. We are particularly interested in NXP's 77–81 GHz FMCW radar solutions and would appreciate your technical guidance on the following questions: 1. Does NXP have any existing technologies, research results, or application examples related to human versus pet (Human / Non-human) classification using mmWave radar? 2. Is it technically feasible to distinguish humans from pets using radar data, such as point clouds and Doppler information, through AI-based classification algorithms? 3. Are there any relevant reference designs, technical documents, or development resources available for this application? We would also appreciate the opportunity to discuss this topic with an NXP radar technical specialist or Field Application Engineer (FAE) in South Korea. Thank you for your time and assistance. I look forward to your response. Best regards, Eunjin Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, Let me look closer if we have done something similar as our RADARs are automotive. Best regards, Peter Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, 1. Does NXP have any existing technologies, research results, or application examples related to human versus pet (Human / Non-human) classification using mmWave radar? NXP does not currently offer a ready-to-use 77–81 GHz reference solution specifically for residential fall detection and human-versus-pet classification. NXP’s 77–81 GHz radar portfolio is primarily intended for automotive radar applications. 2. Is it technically feasible to distinguish humans from pets using radar data, such as point clouds and Doppler information, through AI-based classification algorithms? Human/pet classification using radar is technically feasible in principle. Machine-learning models can use features such as range, velocity, Doppler or micro-Doppler characteristics, spatial distribution and movement over time. Nevertheless, this would require customer-specific data collection, model training and validation under representative residential conditions. Robust performance cannot be guaranteed based on point-cloud data alone; lower-level range-Doppler or range-angle data may be beneficial. 3. Are there any relevant reference designs, technical documents, or development resources available for this application? NXP can provide radar evaluation hardware and signal-processing resources based on the SAF85xx platform to support feasibility evaluation and custom development. These resources do not include a finished fall-detection or pet-classification algorithm. We would also appreciate the opportunity to discuss this topic with an NXP radar technical specialist or Field Application Engineer (FAE) in South Korea. Please get in touch with NXP representative Sales/FAE assigned to your company or with your distributor so the separate support channel can be established. Best regards, Peter

BCC MC33771Cの測定タイミング こんにちは、チームの皆さん、   私たちはMC33771Cバッテリー・セルコントローラ(BCC)を使って作業しており、異なる読み取り間隔を使うと電圧/温度測定の読み取りタイミングに違いがあることが観察されました。   テスト結果：   構成：スレーブ4台を備えた、BCCと同じ構成。 読み取り間隔：10 ms：4 つのスレーブすべてから温度データを読み取るのに約 40 ms かかります。 読み取り間隔: 100 ms: 4 つのスレーブすべてから同じ温度データを読み取るのに約 7.7 ms かかります。 設定は変更されていないにもかかわらず、読み取り間隔を10msに設定すると、測定全体の読み取り時間が著しく長くなることが観察された。   以下の点についてご理解いただけますか?   10ミリ秒と100ミリ秒の読み取り間隔で、測定値の読み取り時間が大きく異なるのはなぜですか？ 読み取り間隔とADC変換、測定値更新、またはBCC通信タイミングの間には、何らかの依存関係がありますか？ 4台のBCCスレーブを使用する場合、電圧/温度の読み取りタイミングを安定かつ最適化するための推奨構成や手順はありますか？ 複数のMC33771Cデバイスから測定データを読み取る際に考慮すべき、特定のタイミング制約や同期要件はありますか？ さらなる分析のために、追加の設定情報や測定ログが必要な場合はお知らせください。 Re: BCC MC33771C measurement timing こんにちは、ニルマルさん。 ADCの設定をご確認いただきありがとうございます。これは重要な補足事項です。ADC_CFG[AVG] = 0、16ビット分解能の場合、ハードウェアtEOCはわずか約520µsです。10ms間隔で40msの読み出し時間が見られるのはADC変換自体によるものではなく、ほぼ間違いなくファームウェアの測定シーケンスによるものです。 tEOCが約520µsの場合、データはどちらの間隔が満了するよりもかなり前に準備完了となる。したがって、観測される読み出し時間の差は、ファームウェアがSOCをトリガーし、間隔に対して結果を読み取る方法とタイミングに起因する。この特定の症状の最も一般的な原因は以下のとおりです。 1. SYS_CFG1[CYCLIC_TIMER]は10msでアクティブになります 周期タイマーが10msに設定されている場合、デバイスは10msごとに自動的に周期変換をトリガーします。ただし、周期的な変換ではMEAS_xxxx測定レジスタは更新されず、OV/UV/OT/UT障害フラグのみが更新されます。MCUファームウェアがオンデマンドSOCを発行する前にサイクリックトリガーを待つと、実効測定サイクルはサイクル周期と連動し、各読み取りまでに最大10msのレイテンシが加算されます。100msの周期周期でこのレイテンシは消えます。なぜならMCUは独立してオンデマンドSOCを発行するためです。SYS_CFG1[CYCLIC_TIMER]の値を確認し、もし有効であれば無効化するか、MCUのリードシーケンスを完全に切り離すことを検討してください。 2. 読み取り前に固定間隔の遅延を挿入（EOCを待たない） ファームウェアがSOCを発行し、EOCフラグをポーリングするのではなく、読み取り間隔全体（10msまたは100ms）待ってから読み取る場合、動作は次のようになります。 100 ms: SOC → 100 ms待機 → 読み取り (7.7 ms 通信) → 測定値 ≈ 7.7 ms ✓ 10 ms: SOC → 10 ms 待機 → 読み取り (7.7 ms 通信) → しかし、サイクルが繰り返され、タイミングが複合すると、実効測定期間が長くなります。 3. SOCはブロードキャストではなく、スレーブごとに発行される ファームウェアが各スレーブに対して個別にSOCをトリガーし、各スレーブ間の読み取り間隔を強制する場合、4つのスレーブの合計は間隔の倍数になります。 4体の奴隷の正しい順序は次のとおりです。 - 4つのスレーブすべてに同時に単一のブロードキャストSOCを発行します。 - EOCフラグをポーリングする（または16ビットで最低520µs待機する、AVG=0）—読み取り間隔と同じ固定遅延は使用しない。 - EOCが確認された後、4つのスレーブすべてを順番に読み込む。 BRs、トーマス お好みの間隔で繰り返してください。 Re: BCC MC33771C measurement timing こんにちは、 @TomasVaverka さん。 詳しい説明をありがとうございました。 私たちの構成では、以下の設定を使用しています。 ADC_CFG[AVG] = 0 ADC分解能 = 16ビット BCCスレーブの数 = 4 両方のテストCASE(10msと100msの読み取り間隔)で同じ構成を使用しています。 しかしながら、以下のようなタイミングのずれが観察された。 10 ms 読み取り間隔: 4 つのスレーブすべてから温度データを読み取るのに約 40 ms かかります。 100 ms 読み取り間隔: 4 つのスレーブすべてから温度データを読み取るのに約 7.7 ms かかります。 ADCの平均化と解像度の設定は両者で同じですが、なぜ変換と測定表示のタイミングが大きく異なるのか、説明していただけますか? この動作を説明するために、SOCトリガー間隔、ADC変換状況、EOCフラグ処理に何か依存関係があるのでしょうか? また、10msの測定間隔で一貫した測定表示タイミングを実現する方法についても提案していただけますか? Re: BCC MC33771C measurement timing こんにちは、ニルマルさん。 タイミングのずれは、おそらくADC_CFG[AVG]の平均化設定が原因です。 平均化が有効になっている場合、tEOC（SOCからデータ準備完了までの時間）はサンプル数に比例して変化します。例えば、16ビット解像度でAVG=64の場合、tEOCは約32.5msとなり、10msの読み取り間隔をはるかに超えます。これは、観察された挙動を説明するものです。 100 ms間隔で:MCUが読み取り→通信時間のみ(~7.7 ms)を測定した時点で変換は完了しています。 10 ms間隔で:MCUは変換完了を待つ必要があります →測定時間=残りのtEOC待ち時間+通信≈40ms。 ご質問に関連する追加事項をいくつかご紹介します。 1. サイクルモード (SYS_CFG1[CYCLIC_TIMER]) は MEAS_xxxx レジスタを更新しません。障害フラグ (OV/UV/OT/UT) のみを更新します。実際の電圧/温度測定値を取得するには、オンデマンドSOCが必要です。平均化機能は、周期モードでは利用できません。 2. 結果を読む前に、必ずEOCフラグが表示されるまで待ってください。読み取り間隔と同じ固定遅延時間は、tEOCを超えることが保証されている場合を除き、使用しないでください。 3. 4台のスレーブの場合：1つのSOCをすべてのスレーブに同時にブロードキャストし（すべてが並列で変換し、tEOCで完了）、その後、順次読み取ります。16ビット、AVG=0の場合、最小合計時間は約0.52ms（tEOC）+ 4×0.7ms（TPL通信）≈3.3msです。 4. フルタイム最適化フレームワークについては、AN12637 MC33771CおよびMC33772Cベースのシステムタイミング最適化(nxp.com で利用可能、ログインが必要)を参照してください。 BRs、トーマス Re: BCC MC33771C measurement timing こんにちは、 @TomasVaverka さん、 SOCにブロードキャストメッセージを使用していますが、それでもタイミングのずれが発生しています。

PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value As part of the code migration task, we are facing an issue where the BSF flag is being set. Due to the BSF flag being set, the EMON bit in the Minutes register is also getting set. As a result, the Minutes value displayed on the screen is showing an arbitrary value. Additionally, the Year value is not being saved correctly and continuously shows 2000 even after setting the RTC date and time. I tried to test the condition mentioned below, but the problem still persists.  I set the flag register (0x43) to 0x00 and read it immediately; it showed 0x00. However, when I read the register again after 3 seconds, the value was set again to 0x08 (or 0x00).   Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Hello Ris_eek Good day! The BSF flag is not simply failing to clear. Instead, the RTC is detecting a new battery switch-over event and setting BSF again. According to the datasheet, BSF is set whenever the battery switch-over logic detects a power transition event The fact that it re-asserts after ~3 seconds means the VDD supply is repeatedly dropping below the battery switch-over threshold causing repeated VDD>VBAT>VDD transitions. Each transition re-sets the BSF. RafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.png This constant voltage fluctuation causes the RTC to constantly reset, which is why it only shows the year 2000. I recommend checking if there's a problem with the power supply signal. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Dear Rafar; Thanks for your mail.    In the hardware, the VDD (4.93 VDC) and VBAT (3.02 VDC) voltages are constant. As a precaution against voltage fluctuations, a 100 nF capacitor is connected across the battery supply. The Battery Switch Register (26h) is set to 0x00. Therefore, the BSM (Battery Switch Mode) is configured to switch at the Vth level. The Vth level is 1.5 V because the BSTH (Battery Switch Threshold Voltage) bit is set to 0. As per Figure 25, referenced in previous email: When VDD < Vth, the BSF is set to 1. When VDD > VBAT, the BSF should be cleared. However, under the power-ON condition, the measured voltage is VDD = 4.93 VDC, which is greater than VBAT = 3.02 V. Even then, the BSF is not cleared. Could you please clarify why the BSF remains set even though VDD is greater than VBAT? Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Hello Ris_eek Good day! The datasheet says the following: The assertion of the flag BSF (register Flags, address 2Bh) can be used to generate an interrupt at pins INTA and INTB. The interrupt can be generated as a pulsed signal or alternatively as a permanently active signal, which follows the condition of bit BSF. BSF remains set until cleared by command. The reference image I sent also indicates the following: "cleared via interface." It’s not automatically, you have to cleared I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Okay RafaR Thank you for this. But the BSF flag is cleared in software, but after some time, it is set again, as described in my previous post. Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value Thanks, Now my code migration for the PCF85263AT/AJ is done. We now want to use the offset register in the RTC to improve clock accuracy and we are using it in OFFM=1 (fast mode). While testing the firmware built for offset correction, we observed that the frequency of the INTA(CLK) pin's signal on a DSO varies between 32.68kHz and 32.80kHz. Please check the attached photo. And the same is being read by our microcontroller as well. Offset Value Calculations for 32.68kHz as per fig 20 under section 7.8.3 of the datasheet: A) Consider: CLKOUT fmeas = 32680 Hz so Tmeas = 30.599755 usec B) Dmeas = 30.517578 usec - 30.599755 usec = -0.082176 usec C) Eppm = 10^6 x (-0.082176/30.599755) = -2685.51169 ppm D) Offset Value (when OFFM=1, i.e. Fast Mode) = -2685.51169/2.0345 = -1319.98 ~ -1320 As per the table no. 24 under section 7.8 of the datasheet, the demonstration shows offset values in decimal from -127 to +128 only. But in our case, we are now not able to understand what is to be written to the OFFSET[7:0] register, when our caluclated value is -1320. Hence, we're unsure how or what to write in the application code, so as to test the offset calibration. Kindly guide us on the next steps.