MC9S12DG256G not reading Port A correctly I am trying to write an assembly language program to read a 16-key matrixed key pad using Port A of the MCU in single-chip mode.  It involves splitting Port A into 2 parts: 4 input pins, and 4 output pins, using the data direction register for port A, DDRA.  Zeroes are then sent out on all 4 output pins simultaneously, and, when a key is pressed, it connects one of those zeroes to one of the input pins, which the MCU then reads at port A and subsequently figures out in which row the key that was pressed is located.  The internal port A pull-ups are activated so that a floating pin will read in as a 1. Here is the part of the code that's causing the problem:  ldaa #%00001111  ;now find ROW staa DDRA            ; 4 output pins, 4 input pins bset PUCR,#$01   ;enable pull-ups on PORTA ldaa #$F0            ;send 0s on column pins staa PORTA ldaa PORTA           ;check which row is 0 [software trap here] The last line, reading Port A, is the problem.  When I hold down a key on the key pad, it does force one of the Port A pins low, as verified by the oscilloscope while the program is running, while the other 3 bits of the high nibble remain high, due the pull-ups.  I would expect, therefore, to find in the A register one of the bits--7, 6, 5, or 4--to be a 0, and the rest ones.  However, the A register always reads 0000xxxx.  I.e., all of the  high nibble bits are 0.  So, when I read Port A, why do I not see the logic levels that I actually measure on the Port A pins? Adding to the conundrum, when I single step through the code using the DBUG-12 monitor, it works perfectly! I am using the Dragon12-Light development board. It is driving me crazy, so I will appreciate any help.  Thank you. Development Board Re: MC9S12DG256G not reading Port A correctly Thank you very much, Lama.  The problem was solved by inserting no fewer than 4 NOPs between write and read to port A, but I also had to add external 10-kOhm pull-ups on all 8 bits of port A.  When I saw that adding the 4 NOPs, alone, reduced the keypad read errors but did not completely eliminate them, and that single-stepping through the code gave no errors, I realized that there had to be a timing / noise problem.  In this case, it was ringing due to the ribbon cable connecting the keypad to port A (please see attached photo).  Unfortunately, the board designer did not terminate the lines between the keypad and port A, so that, when a low was sent from port A, bit 0, to port A, bit 7, for example, through the "C" key switch when pressed, that signal passed through the ribbon cable, whose inductance and capacitance produced significant ringing due to the high 24-MHz bus clock speed.  That ringing persisted longer than several NOP delay times before the signal stabilized at the low logic level, causing false reads.  So, in addition to the internal port A pull-ups, I added 8 external pull-up resistors, which finally fixed the problem.  The NOP delays, I think, could possibly be eliminated or reduced in number if I had carefully taken the time to measure the ringing and properly terminate the lines to eliminate it.  (The board designer apparently just copied the keypad circuitry from his earlier 68HC11 board where the clock frequency was only 2 MHz, and on which my program ran fine with no timing or noise issues).  Thank you again for pointing me in the right direction to finally solve a vexing problem (lab exercise for a college microcontroller class). Re: MC9S12DG256G not reading Port A correctly Hi, Have you thought about speed of information in the internal circuits? I suppose you should enter a small delay (nop or a few nops) between write and read port A. Best regards, Ladislav

MC9S12DG256G 无法正确读取端口 A 我正在尝试编写一个汇编语言程序，以在单片机模式下使用 MCU 的端口 A 读取 16 键矩阵键盘。它涉及将端口 A 分成 2 个部分：4 个输入引脚和 4 个输出引脚，使用端口 A 的数据方向寄存器 DDRA。然后同时在所有 4 个输出引脚上发送零，并且，当按下一个键时，它将其中一个零连接到其中一个输入引脚，然后 MCU 在端口 A 读取该输入引脚，随后找出按下的键位于哪一行。内部端口 A 上拉电阻被激活，因此浮动引脚将读取为 1。 以下是导致问题的代码部分： ldaa #%00001111 ;现在找到 ROW DDRA ； 4个输出引脚，4个输入引脚 bset PUCR,#$01 ;启用 PORTA 上的上拉电阻 ldaa #$F0 ;在列引脚上发送 0 斯塔阿·波尔塔 ldaa PORTA ;检查哪一行是 0 [此处有软件陷阱] 最后一行，即“端口 A”，就是问题所在。当我按住键盘上的某个键时，它确实会强制端口 A 引脚之一处于低电平，这在程序运行时通过示波器进行了验证，而由于上拉，高半字节的其他 3 位仍保持高电平。因此，我期望在 A 寄存器中找到其中一位（7、6、5 或 4）为 0，其余为 1。然而，A寄存器的读数始终为0000xxxx。即所有高半字节位均为 0。 那么，当我读取端口A时，为什么我看不到端口A引脚上实际测量到的逻辑电平呢？更令人困惑的是，当我使用DBUG-12监视器单步执行代码时，它运行正常！ 我正在使用 Dragon12-Light 开发板。 这让我发疯，所以我会很感激任何帮助。谢谢。 开发板 回复：MC9S12DG256G 无法正确读取端口 A 非常感谢你，喇嘛。通过在写入和读取端口 A 之间插入不少于 4 个 NOP，问题得到了解决，但我还必须在端口 A 的所有 8 位上添加外部 10 kOhm 上拉电阻。当我发现仅添加 4 个 NOP 可以减少键盘读取错误但不能完全消除错误，并且单步执行代码不会出现任何错误时，我意识到肯定存在时间/噪声问题。在这种情况下，由于带状电缆将键盘连接到端口 A，所以发出响声（请参见附图）。不幸的是，电路板设计师没有终止键盘和端口 A 之间的线路，因此，当按下“C”键开关时，从端口 A 位 0 向端口 A 位 7 发送低电平信号时，该信号会通过带状电缆传递，由于 24 MHz 的高总线时钟速度，带状电缆的电感和电容会产生明显的振铃。在信号稳定在低逻辑电平之前，该振铃持续时间超过几个 NOP 延迟时间，从而导致错误读取。因此，除了内部端口 A 上拉电阻外，我还添加了 8 个外部上拉电阻，最终解决了该问题。我认为，如果我仔细花时间测量振铃并正确终止线路以消除它，NOP 延迟可能会被消除或减少。（电路板设计师显然只是从他早期的 68HC11 电路板上复制了键盘电路，该电路板的时钟频率只有 2 MHz，我的程序在该电路板上运行良好，没有任何时序或噪音问题）。再次感谢您为我指明了正确的方向，最终解决了一个棘手的问题（大学微控制器课程的实验练习）。

MC9S12DG256GポートAを正しく読み取らない 私は、シングルチップモードでMCUのポートAを使用して16キーのマトリックスキーパッドを読み取るアセンブリ言語プログラムを作成しようとしています。これには、ポートAのデータ方向レジスタであるDDRAを使用して、ポートAを4つの入力ピンと4つの出力ピンの2つの部分に分割することが含まれます。その後、4つの出力ピンすべてに同時にゼロが送信され、キーが押されると、そのゼロの1つが入力ピンの1つに接続され、MCUはポートAで読み取り、押されたキーがどの行にあるかを判断します。内部ポートAプルアップがアクティブになり、フローティングピンが1として読み取られます。 問題の原因となっているコードの一部を次に示します。 LDAA #%00001111 ;次に、ROW を検索します staa DDRA ;出力ピン4本、入力ピン4本 bset PUCR、#$01 ;PORTAでプルアップを有効にする LDAA #$F 0 ;列ピンに 0 を送信 ポルタ駅 ldaa PORTA ;どの行が 0 かを確認する [ソフトウェアトラップはこちら] 最後の行であるポート A が問題です。キー パッドのキーを押したままにすると、プログラムの実行中にオシロスコープで確認されたように、ポート A ピンの 1 つが強制的に Low になりますが、プルアップにより High ニブルの他の 3 ビットは High のままになります。したがって、私は、Aレジスタでビットの1つ(7、6、5、または4)が0であり、残りのビットが1つを見つけることを期待します。ただし、Aレジスタは常に0000xxxxを読み取ります。つまり、上位ニブル ビットはすべて 0 です。 では、ポート A を読み取ったときに、ポート A ピンで実際に測定したロジック レベルが表示されないのはなぜですか?さらに、DBUG-12 モニターを使用してコードを 1 ステップ実行すると、完璧に動作します。 Dragon12-Light開発ボードを使用しています。 それは私を狂わせているので、私はどんな助けでも感謝します。ありがとうございます。 開発ボード Re:MC9S12DG256GポートAを正しく読み取らない ラマさん、ありがとうございました。この問題は、ポート A への書き込みと読み取りの間に 4 つ以上の NOP を挿入することで解決されましたが、ポート A の 8 ビットすべてに外部 10kΩ プルアップを追加する必要もありました。 4つのNOPを追加するだけで、キーパッドの読み取りエラーは減少しますが、完全にはなくならず、コードをシングルステップスルーしてもエラーが発生しないことを見たとき、タイミング/ノイズの問題があるに違いないと気付きました。この場合、キーパッドとポートAをつないでいるリボンケーブルが原因で鳴り響いていました(添付写真参照)。残念ながら、ボード設計者はキーパッドとポートAの間のラインを終端しなかったため、ポートAのビット0からポートAのビット7にローが送信されると、たとえば「C」キースイッチを押して押すと、その信号はリボンケーブルを通過し、そのインダクタンスとキャパシタンスにより、24MHzのバスクロック速度が速いために大きなリンギングが発生しました。このリンギングは、信号がローロジックレベルで安定するまで、数NOP遅延時間よりも長く持続し、誤った読み取りを引き起こしました。そこで、内部ポートAのプルアップに加えて、外部プルアップ抵抗を8個追加し、最終的に問題を解決しました。NOP遅延は、時間をかけてリンギングを測定し、ラインを適切に終了して解消していれば、おそらく解消または削減できたと思います。(ボード設計者は、クロック周波数がわずか2MHzで、私のプログラムはタイミングやノイズの問題もなく問題なく動作した以前の68HC11ボードからキーパッド回路をコピーしたようです)。厄介な問題(大学のマイクロコントローラークラスの実験室演習)を最終的に解決するための正しい方向を指し示してくれて、改めて感謝します。

MIMXRT685-evk not able to debug with j-link I'm a newer to  MCUXpresso IDE. Pre: board: MIMXRT685-EVK official SDK package: SDK_2_16_000_EVK-MIMXRT685.zip Build SDK: ctimer_pwm_with_dutycyle_change without any change. Try to debug with J-link v2 tool. Phenomenon: Debug windows display: evkmimxrt685_sctimer_pwm_with_dutycyle_change JLink Debug [GDB SEGGER Interface Debugging] evkmimxrt685_sctimer_pwm_with_dutycyle_change.axf Thread #1 57005 (Running : User Request) arm-none-eabi-gdb (13.2.90.20231008)   Stuck at ResetISR function in file startup_mimxrt685s.c. __asm volatile ("cpsid i");   Now can't debug next step.   Debugger Console display: warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report. monitor exec SetRestartOnClose=1 I don't know the root cause and Very Need Help. Re: MIMXRT685-evk not able to debug with j-link Hi Mayliu, Thank you very much. Boot mode is wrong.

PCF85363 always runs 3s ahead Hello community, I have bought a PCF85363 and am in the process of testing it. Unfortunately it is running 3 seconds ahead per day. I have tried different settings to adjust the clock. Unfortunately no success. I have also attached capacitors (33pf and 47pF) to the quartz. No success either. At the beginning the clock ran behind, but now it always runs ahead. What am I doing wrong? Yours sincerely Patrick Dreger Re: PCF85363 always runs 3s ahead Standard clock quartz, 32.768kHz with 12.5 load capacity. Re: PCF85363 always runs 3s ahead Hello Thomas, I know that you can do offset calibration. I just wanted to avoid it. It could have been to trick with additional capacitors. And one more thing. This is the best 1Hz clock I have measured with oscillator. No 0.9Hz. Stable 1Hz. 👍 Re: PCF85363 always runs 3s ahead Hello, I use clock quartz with 12.5pF. I have tried all the configurations. I have even changed the quartz. Re: PCF85363 always runs 3s ahead Hello Patrick, What crystal are you using? Is it a 6pF, 7pF or 12,5pF load capacitance crystal? Did you set the load capacitance bits accordingly? It is possible to perform offset calibration as described in the datasheet, section 7.8.3. You can also find some useful info in the UM10301, sections 9  and 10. BRs, Tomas

Inquiry About SDK for CLRC663 plus NFC Frontend Development Kit (OM26630FDK) I am currently testing NFC card read/write functionality using the CLRC663 plus NFC Frontend Development Kit (OM26630FDK). While I have successfully tested the functionality using the NXP NFC Cockpit, I would like to proceed with creating and testing firmware in the MCUXpresso IDE environment. However, I am having difficulty finding the appropriate SDK for this purpose. Could you please let me know if there is an available SDK that supports the CLRC663 plus NFC Frontend Development Kit (OM26630FDK) as a standalone device, without requiring the FRDM-K82F board? Re: Inquiry About SDK for CLRC663 plus NFC Frontend Development Kit (OM26630FDK) Hello @sbchoe Hope you are doing well. CLRC663 plus family devices are NFC Frontends that require the NFC stack to run on a separate system MCU. We provide a NFC Reader Library, which is a complete software support library for our NFC Frontend ICs designed to provide a faster and simpler way to develop your project. This library also provides an API that facilitates the most common operations required in NFC applications such as reading or writing data into contactless cards or tags, and offers support for some host MCUs from our portfolio. If you are interested, you can refer to the following Application Note: Using the RC663 without library. Regards, Eduardo.

i;MX8MP LVDS clock polarity Hi all,  We are using an #i.MX8MP  application processor to drive a LVDS panel on one of our custom board. The panel is currently not looking as expected. The text is barely readable, and we see some black (moving) flicker when we display a red screen. We have contacted the vendor of the panel, and they suggested to invert the polarity of the LVDS clock (from falling edge to rising edge or from rising edge to falling edge depending on the current setting).  We then had a look at the reference manual of the #i.MX8MP. We did not find any relevant registers/information about the clock polarity of the LVDS interface. Do you have some information about the polarity of the clock? What is the default setting? Can this be configured?  We have tried to swap the plus and minus clock signals as an alternative, but that does not work (voltage levels are different, so that is not unexpected). We also tried changing the polarity of the pixel clock in the LCDIF. However, then the panel looked exactly the same. Does someone have some other suggestions to troubleshoot or fix our problem? Kind regards,  Yoshi Re: i;MX8MP LVDS clock polarity Hi,  Thank you for your reply. It was indeed an issues on our PCB.  Kind regards,  Yoshi Re: i;MX8MP LVDS clock polarity Hi @YoshiDev! Is not possible to change the polarity in the iMX8MP. What BSP version are you using? What Display model are you using? Have you configured well the device tree, clock rate, etc? The most of cases behaviors like that are normal when the configuration is not the correct one. I recommend to check your layout and verify the impedance of the LVDS signals too. Best Regards! Chavira

PCF85363は常に3秒先を走ります コミュニティの皆さん、こんにちは。 PCF85363を購入し、テスト中です。 残念ながら、1日あたり3秒先を走っています。 時計を調整するためにさまざまな設定を試しました。残念ながら成功しませんでした。また、クォーツにコンデンサー(33pfと47pF)を取り付けました。成功もしません。 最初は時計が遅れていましたが、今では常に先を進んでいます。 何が間違っているのですか? 草々 パトリック・ドレガー Re:PCF85363は常に3秒先を走ります 標準クロッククォーツ、32.768kHz、12.5の負荷容量。 Re:PCF85363は常に3秒先を走ります こんにちはトーマス、 オフセットキャリブレーションができることは知っています。ただ避けたかっただけです。 追加のコンデンサでごまかすためだったかもしれません。 そしてもう一つ。これは、私が発振器で測定した中で最高の1Hzクロックです。0.9Hzはありません。安定した1Hz。 👍 Re:PCF85363は常に3秒先を走ります こんにちは クロッククォーツは12.5pFで使っています。 私はすべての構成を試しました。クォーツまで交換しちゃいました。

i;MX8MP LVDS クロック極性 皆さん、こんにちは #i.MX8MPアプリケーションプロセッサを使用して、カスタムボードの1つでLVDSパネルを駆動しています。パネルは現在、期待どおりに表示されません。テキストはほとんど読めず、赤い画面を表示すると黒い(動く)ちらつきが見られます。パネルのベンダーに問い合わせたところ、LVDSクロックの極性を反転させることを提案しました(現在の設定に応じて、立ち下がりエッジから立ち上がりエッジへ、または立ち上がりエッジから立ち下がりエッジへ)。 次に、#i.MX8MPのリファレンスマニュアルを見ました。LVDS インターフェイスのクロック極性に関連するレジスタ/情報は見つかりませんでした。時計の極性についての情報はありますか?デフォルト設定は何ですか?これは構成できますか? 代わりにプラスとマイナスのクロック信号を入れ替えようとしましたが、うまくいきません(電圧レベルが異なるため、これは予想外ではありません)。また、LCDIFのピクセルクロックの極性を変更してみました。しかし、その後、パネルはまったく同じに見えました。誰かが私たちの問題をトラブルシューティングまたは修正するための他の提案を持っていますか? よろしくお願いいたします。 ヨッシー

PCF85363 总是提前 3 秒运行 大家好， 我已经购买了 PCF85363 并且正在对其进行测试。 不幸的是，它每天快 3 秒。 我尝试了不同的设置来调整时钟。不幸的是没有成功。我还将电容器（33pf 和 47pF）连接到石英上。也没有成功。 一开始，时钟总是跑得慢，但现在它总是跑得快。 我做错了什么？ 此致 帕特里克·德雷格 回复：PCF85363 总是提前 3 秒运行 标准时钟石英，32.768kHz，负载能力为 12.5。 回复：PCF85363 总是提前 3 秒运行 你好，托马斯， 我知道您可以进行偏移校准。我只是想避免这种情况。 这可能是利用附加电容器的诡计。 还有一件事。这是我用振荡器测量过的最好的 1Hz 时钟。没有0.9Hz。稳定1Hz。 👍 回复：PCF85363 总是提前 3 秒运行 你好， 我使用 12.5pF 的时钟石英。 我已经尝试了所有的配置。我甚至更换了石英。

咨询CLRC663 SDK 以及 NFC 前端开发套件 (OM26630FDK) 我目前正在使用 CLRC663 加 NFC 前端开发套件 (OM26630FDK) 测试 NFC 卡读/写功能。虽然我已经使用 NXP NFC Cockpit 成功测试了功能，但我想继续在 MCUXpresso IDE 环境中创建和测试固件。 但是，我很难找到适合此目的的 SDK。您能否告诉我是否有可用的 SDK 支持 CLRC663 加 NFC 前端开发套件（OM26630FDK）作为独立设备，而不需要 FRDM-K82F 板？

i;MX8MP LVDS 时钟极性 大家好， 我们正在使用#i.MX8MP 应用处理器来驱动我们其中一块定制板上的 LVDS 面板。该小组目前看起来并不像预期的那样。文本几乎无法阅读，当我们显示红色屏幕时，我们会看到一些黑色（移动）闪烁。我们已经联系了面板的供应商，他们建议反转 LVDS 时钟的极性（根据当前设置从下降沿到上升沿或从上升沿到下降沿）。 然后我们查看了#i.MX8MP 的参考手册。我们没有找到任何有关 LVDS 接口时钟极性的相关寄存器/信息。您是否了解一些有关时钟极性的信息？默认设置是什么？这个可以配置吗？ 我们尝试交换正负时钟信号作为替代方案，但这并不奏效（电压水平不同，所以这并不意外）。我们还尝试改变 LCDIF 中像素时钟的极性。然而，面板看起来完全一样。是否有人有其他建议来排除故障或解决我们的问题？ 此致， 耀西

Hard/Bus Fault while running AN12255SW flash_remap_test I'm having trouble running the flash remap test from AN12255SW. Once I finish initializing FlexSPI, I receive a bus fault BFARVALID (7) BusFault Address Register (BFAR) valid flag and PRECISERR (1) Precise data bus error in addition to a forced hard fault. I needed to modify the clock configuration, otherwise the debugger would stop working - I believe this config is correct as I've used it with another flexspi flash example and my debugger remained active afterwards. I'm not sure if maybe I should be setting additional options for the AHB buffer? Also in the flexspi flash example, the flexspi flash driver code is run out of RAM instead of Flash using a linker script, but it doesn't look like that is needed here? int main { uint32_t i = 0; flexspi_config_t config; status_t status; uint8_t vendorID = 0; BOARD_ConfigMPU(); BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); CLOCK_SetMux(kCLOCK_FlexspiMux, 0x2); /* Choose PLL2 PFD2 clock as flexspi source clock. 396M */ CLOCK_SetDiv(kCLOCK_FlexspiDiv, 2); /* flexspi clock 133M. */ SCB_DisableDCache(); // Flash remap registers not used at this point //IOMUXC_GPR->GPR30 = 0; //IOMUXC_GPR->GPR31 = 0; //IOMUXC_GPR->GPR32 = 0; PRINTF("\r\nFLEXSPI example started!\r\n"); /*Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.rxSampleClock = kFLEXSPI_ReadSampleClkLoopbackFromDqsPad; FLEXSPI_Init(EXAMPLE_FLEXSPI, &config); // BUS FAULT OCCURS HERE /* Configure flash settings according to serial flash feature. */ FLEXSPI_SetFlashConfig(EXAMPLE_FLEXSPI, &deviceconfig, kFLEXSPI_PortA1); ... } i.MXRT 106x Re: Hard/Bus Fault while running AN12255SW flash_remap_test How can I set the fuse bits as outlined in AN12255 section 3.2.1? Re: Hard/Bus Fault while running AN12255SW flash_remap_test Thank you. I placed the FlexSPI functions into RAM using a similar method to the 'flexspi_nor_polling' example and I no longer had hard faults. I'm thinking the linker for this example was set up a different way that would have done this for me, but I'm not sure how/if it can work with MCUXpresso. The flash remap test uses the same drivers as the flex spi example (just adding the steps to set the GPR), so I pulled the code in to test it and the remap seemed to work just fine. Re: Hard/Bus Fault while running AN12255SW flash_remap_test Hello Diego, I'm using MCUXpresso and not IAR, is it required for using this example? Re: Hard/Bus Fault while running AN12255SW flash_remap_test Hi @schafbo  Thank you for reaching out! It seems that are you running the demo located in AN1225SW> SW\src\boards\evkmimxrt1060\use_case\flash_remap_test\nor\polling_transfer\, correct ? If yes, which scatter (icf) file did you selected? Below an example for more context.   It is expected that the AN12255 SW was working well when it was released, but this occurred  released sometime ago (2018), I do not know if latest IAR and compiler settings and version are affecting.  Diego Re: Hard/Bus Fault while running AN12255SW flash_remap_test You _definitely_ need to be running out of RAM when calling FLEXSPI_Init() and FLEXSPI_SetFlashConfig(). IIRC, in between those two function calls, the FLEXSPI peripheral will have no LUT sequences, so it won't be able to read anything out of flash. Maybe try wrapping your main() function in AT_QUICKACCESS_SECTION_CODE() and see if that helps? Also, if it's useful, here's how we did this in Mbed OS: https://github.com/mbed-ce/mbed-os/blob/master/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT105x/TARGET_EVK/flash_api.c#L91 Re: Hard/Bus Fault while running AN12255SW flash_remap_test I'm using an iMXRT1062.

SDK for CLRC663 plus NFC Frontend Development Kit (OM26630FDK) に関するお問い合わせ 現在、CLRC663 plus NFC Frontend Development Kit(OM26630FDK)を使用してNFCカードの読み取り/書き込み機能をテストしています。NXP NFC Cockpitを使用して機能のテストに成功しましたが、MCUXpresso IDE環境でファームウェアの作成とテストを進めたいと思います。 しかし、私はこの目的のための適切なSDKを見つけるのに苦労しています。CLRC663 plus NFC Frontend Development Kit(OM26630FDK)をスタンドアロンデバイスとしてサポートするSDKがあれば、FRDM-K82Fボードなしでお知らせください。

Help Needed: Is My Schematic for PN7161 Correct? Hi everyone, I hope you're all doing well! I’ve designed a custom board based on the OM27160A1 reference design and connected it to an ESP32-C6. I’ve recently assembled the board and am now trying to work with the PN7161. Unfortunately, I’m already struggling to read the I2C address, and I’m unsure what might be causing the issue. I’m wondering if something might have gone wrong during the soldering process, or if there’s an issue with my schematic design from the start. To troubleshoot, I’ve included only the reader-relevant portion of my schematic in the attached images. I would greatly appreciate it if someone could kindly review my schematic and let me know if anything looks off. I’m open to any suggestions or feedback to help me get the PN7161 up and running. Thank you so much in advance for your help! Best regards, Alexander Re: Help Needed: Is My Schematic for PN7161 Correct? Thank you for the detailed answer and taking the time to look into my schematics!!! After applying the hardware fixes you mentioned and changing and trying with the software I finally managed to get my reader scanning tags! 🙂 For the Antenna etc. I build it exact the same as mentioned in the design guide, so I dont have to deal with this on my own (for my purpose its enough if it reads the UID atm) Re: Help Needed: Is My Schematic for PN7161 Correct? Hello, Good Day! Thank you very much for your interest in our products. Please consider that the OM2716A1HN evaluation board is not a Reference Design and is not intended to represent a final design recommendation for any particular application. The proper functionality of a final device heavily depends on proper printed-circuit board layout and heat sinking design as well as attention to supply filtering, transient suppression, and I/O signal quality. With that taken into account I would like to point out some differences that were found between the documented design and the design that you shared with us. As already mentioned, VDD(PAD) is connected to a cap that is connected to 3.3v. Should be connected to a grounded cap, and connected directly to VDD(PAD) Same thing happens with VDD(UP) as it should be connected to grounded cap, and connected directly to VDD(UP) as follows:                                  You could consider adding a 10k Resistor form DWL_REQ to GND to ensure the logic state of the pin.                                             C16 has a value of 0.1uF when in the EVK schematic that capacitor has a value of 4.7uF Please check with the XTAL manufacturer that it has everything it needs to work properly and confirm that it meets the specs of our recommended hardware. It is also, important to point out that resistors R8, R9, R10, R11 are well connected in the schematic, but should not all be placed during assembly of the board given that they interfere in the I2C address selection of the reader. In order to meet the proper range of valid addresses, the resistors should be connected (on the PCB) as follows:                                 R10 is equal to custom R10 R11 is equal to custom R11 R12 is equal to custom R8 R13 is equal to custom R9 Please refer to PN7160 Hardware Design Guide to find out more about recommended hardware specifications. I would also recommend checking out OM27160 User Manual to get a deeper understanding on how the Evaluation Board works, its possible hardware modifications and how this interacts with the signals. If you continue having trouble reading NFC cards, please make sure you stick to the PN7160 antenna design and matching guide specifications, since hardware variations can interfere with the proper functionality of the antenna. Also, consider checking out some of the NFC Antenna Design training videos that we offer publicly, as well as the AN11535 Application Note on the use of a Vector Network Analyzer (VNA) which is required for proper antenna tuning.  Unfortunately we may not be able to provide further support regarding the software you are using, as we limit the support scope to our recommended libraries, some of which can be downloaded from https://www.nxp.com/doc/SW6705 and easily ported to any other host providing I2C communication as described in NXP-NCI2.0 MCUXpresso examples guide, although keep in mind that porting to third-party platforms is out of our support scope. My best regards, Daniel. Re: Help Needed: Is My Schematic for PN7161 Correct? Hey thans for the feedback! Yes you are completely right I messed up there a little bit and now resoldered it and connected C21 to Ground and V3.3 before the connection. I can connect the module over I2C and I tried using the beta test firmaware for arduino / ESP32 from here https://github.com/ElectronicCats/ElectronicCats-PN7150/releases/tag/v3.0.0-beta But im not able to detect any cards. Can you see any other error in my schematics or do you know any ways to measure it? Re: Help Needed: Is My Schematic for PN7161 Correct? Hi first look is a problem on C21 that can not work at this point please check

[K32w041/K32061]有勘误表吗？ K32W041 或 K32W061 处理器是否有勘误表文档？ 我想知道硬件存在哪些问题，以便能够创建更稳定的产品。 我所知道的例子足以成为发布此类文件的理由： - 掉电检测具有重置 CPU 的功能，但会一直保持 CPU 重置状态，直到硬重置或 PAD RSTN。这使得此重置功能作为安全功能（几乎）毫无用处。 - 不支持同步 ADC？有强烈的迹象表明 ADC 的同步模式不受支持，请参阅 K32W061.h 中 ASYNMODE 的注释： ASYNMODE - 选择时钟模式。0：同步模式。不支持。 但是用户手册 UM11323 修订版 1.2（NXP 网站上的最新版本）指出：“有两种时钟模式可用：同步模式和异步模式。” 回复：[K32w041/K32061]是否有勘误表文档？ 谢谢，我觉得自己很愚蠢，没有找到该文件，但我发现该文件还不到 1 个月。

S32K344 SPI + DMA Lpspi_Ip_AsyncTransmitFast This question might be similar to this one: https://community.nxp.com/t5/S32K/S32K312-LPSPI-DMA-AsyncTransmitFast/m-p/1923811  I have to send two spi transaction to a device. I am trying to use Lpspi_Ip_AsyncTransmitFast. const Lpspi_Ip_FastTransferType ft[] = { { .ExternalDevice = &Lpspi_Ip_DeviceAttributes_SpiExternalDevice_0_Instance_0, .TxBuffer = txbuf_wren, .RxBuffer = rxbuf_wren, .DefaultData = 0, .Length = 1, .KeepCs = false, }, { .ExternalDevice = &Lpspi_Ip_DeviceAttributes_SpiExternalDevice_0_Instance_0, .TxBuffer = txbuf, .RxBuffer = rxbuf, .DefaultData = 0, .Length = 10, .KeepCs = false, } }; void send_spi_txn(void) { Lpspi_Ip_StatusType status = Lpspi_Ip_AsyncTransmitFast( ft, 2, Lpspi_Ip_Callback_lpspi_0_dma ); if (status != LPSPI_IP_STATUS_SUCCESS) { failed_spi_dma = true; } }   I have already tested using Lpspi_Ip_AsyncTransmit to send a single transaction and then sending another one from the completion callback, but this is obviously not ideal so would like to be able to use the transferlist instead. The issue is that no data is being sent. the first time Lpspi_Ip_AsyncTransmitFast is called it reports success, but every subsequent call fails. also can see that there are no spi transfers. on the logic analyzer, but when i just do Lpspi_Ip_AsyncTransmit everything works fine. Re: S32K344 SPI + DMA Lpspi_Ip_AsyncTransmitFast Hello, is there any further update on this topic? is there any example project available. Re: S32K344 SPI + DMA Lpspi_Ip_AsyncTransmitFast Unfortunately I can't post the project because I am only using S32DS to configure the RTD and to generate driver config files. But I was able to work through the issues and unsurprisingly it was a data cache issue with the DMA. as for the setup issues: didn't properly link the scatter gather channels. (each channel needs to link to the next one and last one needs to be marked as final) didn't have the tx/rx dma channels priorities correctly (rx higher than tx) didn't have the tx/rx dma channel complete interrupts prioritized correctly. (tx higher than rx) and the data cache issue boiled down to the MemMap.h files. nxp uses these defines: #define MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #include "Mcl_MemMap.h" /* Pointer to the DMA Initialization Configuration. Based on this configuration pointer, the DMA Driver obtains all information for the Logic Channels and corresponding Channel Configurations. The Pointer is loaded when Dma_Ip_Init() is called. */ static const Dma_Ip_InitType * Dma_Ip_pxInit; #define MCL_STOP_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #include "Mcl_MemMap.h" and in the  _MemMap.h they define what the compiler should do. in this case #pragma GCC section bss ".mcal_bss_no_cacheable" #ifdef MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE /** * @file Mcl_MemMap.h */ #undef MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #define ENTERED_MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #ifndef MEMMAP_MATCH_ERROR #define MEMMAP_MATCH_ERROR #else #ifndef MCL_STOP_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #error "MemMap.h, no valid matching start-stop section defined." #endif #endif /** * @file Mcl_MemMap.h */ #undef MEMMAP_ERROR #pragma GCC section bss ".mcal_bss_no_cacheable" #endif   for gcc unless you use the gcc version that comes with the s32ds ide or download their specific version of gcc these types of pragmas aren't supported. so for now i just went through all the rtd files that used dma and manually added the right section attributes to make them non-cacheable either .mcal_bss_no_cacheable or .mcal_data_no_cacheableso for the snippet above i had to add:   __attribute__((section(".mcal_bss_no_cacheable"))) static const Dma_Ip_InitType * Dma_Ip_pxInit; i replaced all the  _MemMap.h with empty dummy files to make the compiler happy which means i have to manually add all the __attribute__((section())) compiler directives. Re: S32K344 SPI + DMA Lpspi_Ip_AsyncTransmitFast Hi @not_a_duck, Could you share the project so that I can test it? Thank you, Daniel Re: S32K344 SPI + DMA Lpspi_Ip_AsyncTransmitFast correction: `Lpspi_Ip_LPSPI_0_IrqTxDmaHandler` actually does get called but only once. and then never again Re: S32K344 SPI + DMA Lpspi_Ip_AsyncTransmitFast @PetrS or @davidtosenovjan do either of you have any suggestions on what i can check? one additional thing i have noticed is that the dma interrupt for the tx channel is being called repeatedly. it is supposed to call Lpspi_Ip_LPSPI_0_IrqTxDmaHandler callback but it never does.

S32K344 SPI + DMA LPSPI_IP_异步传输快速 这个问题可能与以下问题类似： https://community.nxp.com/t5/S32K/S32K312-LPSPI-DMA-AsyncTransmitFast/mp/1923811 我必须向一个设备发送两个 spi 事务。我正在尝试使用 Lpspi_Ip_AsyncTransmitFast。 const Lpspi_Ip_FastTransferType ft[] = { { .ExternalDevice = &Lpspi_Ip_DeviceAttributes_SpiExternalDevice_0_Instance_0, .TxBuffer = txbuf_wren, .RxBuffer = rxbuf_wren, .DefaultData = 0, .Length = 1, .KeepCs = false, }, { .ExternalDevice = &Lpspi_Ip_DeviceAttributes_SpiExternalDevice_0_Instance_0, .TxBuffer = txbuf, .RxBuffer = rxbuf, .DefaultData = 0, .Length = 10, .KeepCs = false, } }; void send_spi_txn(void) { Lpspi_Ip_StatusType status = Lpspi_Ip_AsyncTransmitFast( ft, 2, Lpspi_Ip_Callback_lpspi_0_dma ); if (status != LPSPI_IP_STATUS_SUCCESS) { failed_spi_dma = true; } } 我已经测试过使用 Lpspi_Ip_AsyncTransmit 发送单个事务，然后从完成回调发送另一个事务，但这显然不是理想的，所以希望能够使用传输列表。 问题是没有数据被发送。第一次调用 Lpspi_Ip_AsyncTransmitFast 时报告成功，但后续每次调用都失败。还可以看到没有 spi 传输。在逻辑分析仪上，但是当我只执行 Lpspi_Ip_AsyncTransmit 时，一切工作正常。 回复：S32K344 SPI + DMA LPSPI_IP_AsyncTransmitFast 不幸的是我无法发布该项目，因为我只使用 S32DS 来配置 RTD 和生成驱动程序配置文件。 但我能够解决这些问题，不出所料，这是 DMA 的数据缓存问题。 至于设置问题： 没有正确链接散射聚集通道。（每个频道都需要链接到下一个频道，最后一个频道需要标记为最终频道） 没有正确设置 tx/rx dma 通道优先级（rx 高于 tx） 没有正确确定 tx/rx dma 通道完成中断的优先级。（tx 高于 rx） 数据缓存问题归结于 MemMap.h文件。 nxp 使用以下定义： #define MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #include "Mcl_MemMap.h" /* Pointer to the DMA Initialization Configuration. Based on this configuration pointer, the DMA Driver obtains all information for the Logic Channels and corresponding Channel Configurations. The Pointer is loaded when Dma_Ip_Init() is called. */ static const Dma_Ip_InitType * Dma_Ip_pxInit; #define MCL_STOP_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #include "Mcl_MemMap.h" 并且在 _MemMap.h它们定义了编译器应该做什么。在这种情况下 #pragma GCC 部分 bss “.mcal_bss_no_cacheable” #ifdef MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE /** * @file Mcl_MemMap.h */ #undef MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #define ENTERED_MCL_START_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #ifndef MEMMAP_MATCH_ERROR #define MEMMAP_MATCH_ERROR #else #ifndef MCL_STOP_SEC_VAR_CLEARED_UNSPECIFIED_NO_CACHEABLE #error "MemMap.h, no valid matching start-stop section defined." #endif #endif /** * @file Mcl_MemMap.h */ #undef MEMMAP_ERROR #pragma GCC section bss ".mcal_bss_no_cacheable" #endif   对于 gcc，除非您使用 s32ds ide 附带的 gcc 版本或下载其特定版本的 gcc，否则不支持这些类型的编译指示。 所以现在我只是检查了所有使用 dma 的 rtd 文件，并手动添加了正确的部分属性，使它们不可缓存 .mcal_bss_no_cacheable 或者 .mcal_data_no_cacheableso 对于上面的代码片段我必须添加：   __attribute__((section(".mcal_bss_no_cacheable"))) static const Dma_Ip_InitType * Dma_Ip_pxInit; 我更换了所有 _MemMap.h 使用空的虚拟文件来使编译器满意，这意味着我必须手动添加所有__attribute__ ((section())) 编译器指令。 回复：S32K344 SPI + DMA LPSPI_IP_AsyncTransmitFast 更正：` Lpspi_Ip_LPSPI_0_IrqTxDmaHandler`实际上确实被调用了，但只调用了一次，之后就再也没有调用过了。 回复：S32K344 SPI + DMA LPSPI_IP_AsyncTransmitFast @PetrS或@davidtosenovjan你们对我可以检查什么有什么建议吗？ 我注意到的另一件事是，tx 通道的 dma 中断被重复调用。它应该调用 Lpspi_Ip_LPSPI_0_IrqTxDmaHandler 回调，但它从来没有调用过。

PCA9509P VOL on PORT A Hello team, What is is the meaning of "Iload=100µA"  in table 6? Is the test circuit shown in Figure 20, with RL=1.35kohms  used for this characterization? Best regards. Sylvain Re: PCA9509P VOL on PORT A Hello Thomas, As the solution will  be implemented in a design, I need an "official answer" from NXP. The answer “I don't think so” is not safe from my point of view  :-). An answer starting with “yes/no 100µA is a strict requirement” will be appreciated. Regards Re: PCA9509P VOL on PORT A Hello Sylvain, I do not think that 100μA is a strict requirement. Please try increasing the pull-up resistor on Port A to reduce the current and check if your VOL improves while keeping rise times within acceptable limits for your application. BRs, Tomas Re: PCA9509P VOL on PORT A Hello, I need some recommandations about Pullup on port A: In paragraph 6.4.1.2, it's written that he pull-up resistor on the A side of the PCA9509P should be chosen to provide at least 100 μA of pull-up current. Is-it mandatory to respect this condition? In my application the VIL of of the master is 0.3XVCC where as the VOL (side A)of PCA9509P is  0.25VCCA (maximum value). The power supply is 1.8V. so VIL(min)=0.3*1.8=0.54V and VOL(max)@100µA=0.25*1.8 =0.45V The margin is : VIL(min)-VOL(max)= 0.54-0.45=0.09V. This margin is very small, so I think that if I reduce  current in port A, the VOL of Port A will be also reduced and the margin will increased. isn't it? Sylvain     Re: PCA9509P VOL on PORT A Hello Sylvain, The PCA9509P is relatively old device and I did not find the relevant test details/results. However, I assume that the "Iload = 100µA" in Table 6 specifies the test condition under which the VOL on Port A was characterized. When the device is driving the output low, it must maintain the VOL value while sinking a current of 100µA. I do not think the circuit in Figure 20 was used directly for the VOL test in Table 6. The load current would be in mA range which significantly exceeds the 100µA condition specified for VOL characterization. BRs, Tomas

QorIQ LS1088A(rdb) increasing the CORE frequency from 1.2 GHz to 1.6 GHz Hello experts, I have LS1088a based custom board. When I power on the device, the processor clock configuration in u-boot(boot by SD) is running at 1.2 GHz.  SoC: LS1088AE Rev1.0 (0x87030010) Clock Configuration: CPU0(A53):1200 MHz CPU1(A53):1200 MHz CPU2(A53):1200 MHz CPU3(A53):1200 MHz CPU4(A53):1200 MHz CPU5(A53):1200 MHz CPU6(A53):1200 MHz CPU7(A53):1200 MHz Bus: 500 MHz DDR: 1600 MT/s How do I increase the core frequency to 1.6GHz? If the clock configuration is related to RCW, which document and which section should I review?  Some components were used differently compared to the reference design. If you have any questions about these, I will get back to you immediately. Thank you. Re: QorIQ LS1088A(rdb) increasing the CORE frequency from 1.2 GHz to 1.6 GHz The DDR controller configuration parameters are different when DDR data rate are 2100 MT/s and 1900 MT/s.  Please use QCVS DDRv tool to connect to the target board to do DDR validation and optimization to get DDR controller configuration parameters at 2100 MT/s DDR data rate. Then use these parameters to modify plat/nxp/soc-ls1088a/ls1088ardb/ddr_init.c according to the file generated by QCVS DDR tool. You could create a new thread to continue to discuss DDR validation issue. Re: QorIQ LS1088A(rdb) increasing the CORE frequency from 1.2 GHz to 1.6 GHz @yipingwang Thank you for your support. CPU runs 1.6GHz and I increased DDR data rate to 1900 MT/s at now.  Clock Configuration: CPU0(A53):1600 MHz CPU1(A53):1600 MHz CPU2(A53):1600 MHz CPU3(A53):1600 MHz CPU4(A53):1600 MHz CPU5(A53):1600 MHz CPU6(A53):1600 MHz CPU7(A53):1600 MHz Bus: 500 MHz DDR: 1900 MT/s When I try to 2100 MT/s data rate (MEM_PLL_RAT=21), I got this error: ERROR: Found training error(s): 0x2000 ERROR: Error: Waiting for D_INIT timeout. ERROR: Writing DDR register(s) failed ERROR: Programing DDRC error ERROR: DDR init failed. NOTICE: Incorrect DRAM0 size is defined in platfor_def.h ERROR: mmap_add_region_check() failed. error -22 ERROR: mmap_add_region_check() failed. error -22 I looked through the LS1088ARM document a bit, but I couldn't see the exact value ranges. What values ​​do I need to assign to work at a data rate of 2100 MT/s? Sys PLL Ref clock:100MHz and My current RCW values ​​are as follows: SYS_PLL_RAT=7 /* 5 */ MEM_PLL_RAT=21 CGA_PLL1_RAT=16 CGA_PLL2_RAT=16 HWA_CGA_M1_CLK_SEL=2 HWA_CGA_M2_CLK_SEL=1 DDR_REFCLK_SEL=2 DRAM_LAT=1 Re: QorIQ LS1088A(rdb) increasing the CORE frequency from 1.2 GHz to 1.6 GHz Please configure the following fields in RCW, please refer to "4.8.7.8.1 RCW" in LS1088ARM. CGA_PLL1_RAT CGA_PLL2_RAT For example, Sys PLL Ref clock:100MHz CGA_PLL1_RAT=16 CGA_PLL2_RAT=16