Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
NTM88 中发生 P-cell 或 g-cell 错误的情况是什么? 我正在使用 NTM88H135ST1 作为我的 BLE TPMS,我想在我的传感器中实现诊断和错误通知。在浏览固件库用户指南时,我得到了这个函数 TPMS_WIRE_AND_ADC_CHECK,有人可以解释一下这个函数出现 P-Cell 和 g-Cell 错误时的条件是什么吗,以便我可以重新创建该条件并对其进行测试。一旦发生错误我们该如何解决呢? 回复:NTM88 中出现 P-cell 或 g-cell 错误的情况是什么? 谢谢托马斯, 类似地,如果以下函数返回错误,那么有什么方法可以恢复它们,或者这些错误也表明 IC 的永久性损坏,TPMS_READ_TEMPERATURE、TPMS_COMP_TEMPERATURE、TPMS_READ_VOLTAGE、TPMS_COMP_VOLTAGE、TPMS_READ_PRESSURE、TPMS_COMP_PRESSURE
查看全文
ADC triggering on the wrong pin Hello,  I ran into an issue on the s32k311 with the RTD 5.0.0. I am using Tresos 29.0.0. So, I want to use Adc0_s14 on the pin Ptc16 but it is triggering on the pin Ptb0. The channel is always reading close to max count because ptb0 is my Spi chip select. The channel is supposed to read close to 1.0V. To confirm, I changed Ptb0 to a Gpio and I triggered the Adc while toggling the pin. I was now reading values alternating between 0 and max count.  I feel like the issue is similar to this one: https://community.nxp.com/t5/S32K/S32K3-ADC-Channcal-configure-problem/td-p/1527680  Do we have a fix for the RTD 5.0.0 concerning this type of issue?  Re: ADC triggering on the wrong pin Thank you, Robin. The solution mentioned is working. Re: ADC triggering on the wrong pin Hi  Sorry for the inconvenience we bring you! This issue is discussed here: S32K311_S32K310 ADC mux-mode channels was abnormal I will send you the S32K311_ADC_Mux_Control.xlsx. Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
查看全文
MIPI DSI on i.MX8MM not working on Scarthgap After switching to the Scarthgap release from Kirkstone, the kenrnel does not bind the DSI devices to each other and the DSI-HDMI-Bridge LT8912b is not working any more. The kernel switched from 5.15 to 6.6. Did any changes occur, that could cause this? I did not change the device tree (Custom Board). This messages keep repeating infinitly: [ 16.051534] imx-drm display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops) [ 16.059264] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200 [ 16.066360] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e10000 to encoder DSI-34: -517 [ 16.078073] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi [ 16.086355] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517 [ 16.095315] lt8912 1-0048: failed to find dsi host i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: MIPI DSI on i.MX8MM not working on Scarthgap The problem seems to result from a patch (d89078c37b10f05fa4f4791b71db2572db361b68) moving the lt8912_attach_dsi call from the lt8912_bridge_attach to probe function. Reverting this patch (introduced with Kernel 5.17) solves the problem. Thanks to @Zhiming_Liu for the hint in this post (https://community.nxp.com/t5/i-MX-Processors/IMX93-DSI-drm-drm-bridge-attach-ERROR-failed-to-attach-bridge/m-p/1894061)
查看全文
MC9S12XEP XGATE スプリアス・インターラプト MC9S12XEP100アプリケーションを使用していますが、次の割り込みが発生しています。 ECT0ISR ECT2ISR-XGATE ECT3ISR PIT1ISR rxcan0isr rxcan3isr txcan0isr TIM3ISR-XGATE TIM4ISR-XGATE 大量のCAN0データを受信していて、3つのECT ISRがすべて有効になっているときに、" スプリアス割り込み " が時折発生します。(ECT ISRのコンテンツがそれぞれのECT_TFLG1をリセットしているだけの場合でも)。 XGATE ECT2ISRを無効にすると(同じ量のCAN0トラフィックで)、スプリアス割り込みは発生しません。私がXGATEを実装したのは、" Freescale\ CWS12V5.1\ (codeWarrior_Examples)\ HCS12X\ S12XE_XGATE_SETUP " という例に基づいています。この例ではROUTE_INTERRUPTマクロを使用してECT2ISR、TIM3ISR、TIM4ISRをXGATEに割り当てています。 XGATEのスプリアス割り込みの原因は何でしょうか?他にどんなトラブルシューティングができますか? よろしくお願い申し上げます。 Re: MC9S12XEP XGATE スプリアス・インターラプト 問題は、メインプロセッサのECT3ISRとXGATEのECT2ISRの両方が同じ1 PPS信号によってトリガーされていたことでした。そして、XGATE ECT2ISRの内部では、次の方法で割り込みフラグをクリアしていました。 ECT_TFLG1_C2F = 1U これは、メインプロセッサがISRを実行する前にメインプロセッサのECT3フラグを誤ってクリアしていたため、スプリアス割り込みが発生していたと思います。 XGATE割り込みを更新して、代わりに次の方法でクリアしました。 ECT_TFLG1 = 4U そして今、すべてが正常に機能しています。 ご協力ありがとうございます。
查看全文
S32K144 IAR Project Build I want to create an IAR project by following the S32DS routine about S32K144. After the project is compiled, I get an error when I enter debug mode. I also tried to export the xml file from the S32DS routine to create the project, again this error occurs, but it can be debug in S32DS. This is the IAR project I created, which configuration items will have problems in the interim? Thanks for help Re: S32K144 IAR Project Build Thanks for your help. Re: S32K144 IAR Project Build Hi @Embedded_novice This seems to be an issue with using J-Link instead of I-Jet. Please look at the following posts: Solved: Re: S32K311 Stack pointer is setup to incorrect alignment - NXP Community [SOLVED] Stack pointer is setup to incorrect alignment - J-Link/Flasher related - SEGGER - Forum You could also try to export the project to IAR EW instead: S32K1xx Series MCU Application Development Guide - IAR toolchain Sample Engineering and Usage FAQ (qq.com) HOWTO: Export S32DS Project to IAR EW (S32K14x/S32K11x) - NXP Community Best regards, Julián
查看全文
HAB event data on imx8mq Hi, We followed the Android Security User Guide of Android 9 to build u-boot with CONFIG_SECURE_BOOT=y and run it on our custom board. SRK has been programmed. And got hab events in hab_status as below. Can someone kindly help us to fit it? u-boot=> hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 --------- HAB Event 1 ----------------- event data: 0xdb 0x00 0x14 0x44 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x40 0x1f 0xdd 0xc0 0x00 0x00 0x00 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 2 ----------------- event data: 0xdb 0x00 0x14 0x44 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x40 0x1f 0xcd 0xc0 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 3 ----------------- event data: 0xdb 0x00 0x3c 0x44 0x33 0x18 0xc0 0x00 0xca 0x00 0x34 0x00 0x02 0xc5 0x1d 0x00 0x00 0x00 0x0d 0x5c 0x40 0x1f 0xcd 0xc0 0x00 0x00 0x10 0x20 0x40 0x20 0x00 0x00 0x00 0x0a 0xd7 0xf0 0x40 0x2a 0xd7 0xf0 0x00 0x00 0x6f 0xd0 0x00 0x91 0x00 0x00 0x00 0x00 0x95 0xd0 0x56 0x00 0x00 0x00 0x00 0x07 0x5c 0x80 STS = HAB_FAILURE (0x33) RSN = HAB_INV_SIGNATURE (0x18) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Re: HAB event data on imx8mq Hi, An assertion event means that one of the following required areas is not signed as documented in the Operation section for authenticate_image() API: Have a reference to the HAB4_API. The document is with CST tool. Regards Harvey
查看全文
MPC5777C - Performance Monitors outside the core Hello! I know that the e200z7 core has a PMU (Performance Monitoring Unit) which can count hardware events. However, I would like to know if the MPC5777C has more performance monitors outside the core that can count events like misses in the PFLASH mini-cache, for example. Best regards, Matheus. Re: MPC5777C - Performance Monitors outside the core So every monitor that can count hardware events are listed in the Performance Monitor chapter of the e200z7 core RM? - Basically yes, you are right. Does not the peripherals have performance monitors themselves? - No, they don't have. Does not the Nexus debug module have performance monitoring features? - Nexus may have TRACE feature, offering lot of capabilities that are however rather feature of the tools itself. You may see for instance following: https://www.nxp.com/docs/en/application-note/AN4591.pdf Re: MPC5777C - Performance Monitors outside the core Thank you for the reply, David! So every monitor that can count hardware events are listed in the Performance Monitor chapter of the e200z7 core RM? Does not the peripherals have performance monitors themselves? Does not the Nexus debug module have performance monitoring features? Best regards, Matheus Re: MPC5777C - Performance Monitors outside the core I have been dealing with Performance monitor in the following thread, pay attention to links at the bottom: https://community.nxp.com/t5/MPC5xxx/cant-write-in-MPC5744P-performance-monitor-registers/td-p/1496274 However performance monitor is a feature of e200 core. The most external event are BIU (bus interface unit) related.
查看全文
S32K312プラットフォームでSafeRTOSサンプルコードをサポートしているRTDのバージョンはどれですか? FreeRTOSをサポートしており、開発用のサンプルコードもあることは知っていましたが、アプリケーションの安全性を高めることを考えています。SafeRTOS のサンプル コードはいつ提供する予定ですか?実行できる RTD バージョン。感謝。
查看全文
How can I change the PLL output frequency of the i.MX7D Hellow. How can I change the PLL output frequency of the i.MX7D. I couldn't find it in the PLL section of the reference manual. Thank you. Re: How can I change the PLL output frequency of the i.MX7D since you use imx7d, your dts file should includes 7d.dtsi, for 7d cpu frequency settings, you can refer to the 7d.dtsi, for M core, you can download SDK for reference MCUXpresso SDK Builder Re: How can I change the PLL output frequency of the i.MX7D Hi. joanxie. I understand that it is set in Device-Tree. However, imx7d.dtsi include imx7s.dtsi and I have made settings there as well, so whitch one takes priority? The same setting is available in u-boot, but is it also necessary for Linux? I have one more question. where do I configure the COrtex-M4? Thank you. Re: How can I change the PLL output frequency of the i.MX7D do you use linux? if yes, you can set this in the dtsi file, find the opp-table  https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm/boot/dts/nxp/imx/imx7d.dtsi Re: How can I change the PLL output frequency of the i.MX7D Hi.  Joanxie. Please see page 505 of reference manual. The frequency of "pll_arm_main_clk"  ranges from 800MHz to 1.2GHz, but I whoud like to set it to 800MHz. Is it possible? Thank you.  Re: How can I change the PLL output frequency of the i.MX7D which pll do you need to change?
查看全文
Schematic / AT-F DTS mismatch on S32G-VNP-RDB3 Evaluation Board I am looking at the schematic and device tree for the arm trusted firmware on the S32G-VNP-RDB3 board and see what looks like a mismatch in netnames and the pinctrl functionality with respect to the PFE pins. This is a pictue from the schematic showing that the RGMII_B_* net pins are labelled as PFE_MAC2_* on the S32G side. Looking at the device tree and cross-referencing the S32G3_IOMUX.xlsx spreedsheet I see that they are actually mapped to PFE_MAC0_* internally.  Here is a snippet from the device tree @ https://github.com/nxp-auto-linux/arm-trusted-firmware/blob/0cd12bb2630a23e760683bf3d911e3c1e282efd5/fdts/s32g.dtsi#L1141C1-L1328C1 And here I added comments to show how the functional groups for the pins map according to the spreadsheet... pfe0_pins: pfe0 { pfe0_grp0 { pinmux = , /* PFE_MAC0_TX_EN_O */ , /* PFE_MAC0_TXD_O[1] */ , /* PFE_MAC0_TXD_O[2] */ , /* PFE_MAC0_TXD_O[3] */ ; /* PFE_MAC0_TXD_O[0] */ output-enable; slew-rate = ; }; pfe0_grp1 { pinmux = , /* GPIO / PFE_MAC0_RX_CLK_I */ , /* GPIO / PFE_MAC0_RXDV_I */ , /* GPIO / PFE_MAC0_RXD_I[0] */ , /* GPIO / PFE_MAC0_RXD_I[1] */ , /* GPIO / PFE_MAC0_RXD_I[2] */ ; /* GPIO / PFE_MAC0_RXD_I[3] */ input-enable; slew-rate = ; }; pfe0_grp2 { pinmux = ; /* PFE_MAC0_TX_CLK_O */ output-enable; slew-rate = ; bias-pull-up; }; pfe0_grp3 { pinmux = , /* GPIO / PFE_MAC0_RX_CLK_I */ , /* GPIO / PFE_MAC0_RXDV_I */ , /* GPIO / PFE_MAC0_RXD_I[0] */ , /* GPIO / PFE_MAC0_RXD_I[1] */ , /* GPIO / PFE_MAC0_RXD_I[2] */ ; /* GPIO / PFE_MAC0_RXD_I[3] */ }; }; So my question is basically are the S32G side nets on the schematic mislabelled and should actually read PFE_MAC0_*? I am using this as the reference for a custom design and want to make sure I have the correct understanding. Thanks. Re: Schematic / AT-F DTS mismatch on S32G-VNP-RDB3 Evaluation Board Hello @minersrevolt , For what I can see you were able to solve your questions. Is that correct? if not, please let us know the exact open points or doubts you might still have so we can support you. Thanks Re: Schematic / AT-F DTS mismatch on S32G-VNP-RDB3 Evaluation Board Looking at the Linux DTS looks like the Functional Groups actually match MAC2 so it is just the AT-F that is out of sync. https://github.com/nxp-auto-linux/linux/blob/adceb7e8fa72c4f26207356a5a33b55b0838717f/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi#L341C1-L398C4 pfe2mdiob_pins: pfe2mdiob_pins { pfe2mdiob_grp0 { pinmux = ; output-enable; slew-rate = ; }; pfe2mdiob_grp1 { pinmux = ; output-enable; input-enable; slew-rate = ; }; pfe2mdiob_grp2 { pinmux = ; }; }; pfe2rgmiib_pins: pfe2rgmiib_pins { pfe2rgmiib_grp0 { pinmux = , , , , ; output-enable; slew-rate = ; }; pfe2rgmiib_grp1 { pinmux = , , , , , ; input-enable; slew-rate = ; }; pfe2rgmiib_grp2 { pinmux = , , , , , , ; }; pfe2rgmiib_grp3 { pinmux = ; output-enable; slew-rate = ; bias-pull-up; }; };
查看全文
S32k3用のFS26パッケージをインストールする方法は? FS26 パッケージをインストールしたいのですが、s32 のインストール タブで見つかりません
查看全文
How to install FS26 packages for S32k3? I want to install FS26 packages but I am unable to find it in install tab in s32 Re: How to install FS26 packages for S32k3? Hi@pranav_prabhu First download the FSxx version corresponding to the RTD version you are currently using, then you can install it in the “S32 DS->Help->Install New Software” interface https://www.nxp.com/products/power-management/pmics-and-sbcs/system-basis-chips/safety-system-basis-chip-with-low-power-for-asil-d-systems:FS26
查看全文
S32DS Licence Problem Hello, I am not able to reinstall S32DS due to a licence problem. (Fullfillment ID 197733417) I cannot return the licence or remove it from my account. I do not have S32DS currently installed. Also, what is the correct procedure so that this does not happen again? Thank you! Activation | Installation | Licensing | Installer Download Re: S32DS Licence Problem Hi @greyes  I think you are confused, the licenses shown are not for S32 Design Studio for the S32 platform, they are S32K3 software licenses. I cannot determine which one it is, but if you press the "Details" button it will send you to a page that provides all the details of the license. You can find the S32DS activation code directly on the IDE page: S32 Design Studio 3.5 > S32 Design Studio for S32 Platform v.3.5 > License Keys tab.  BR, VaneB
查看全文
EIQ version problem The default version of eIQ is 2.10 . The current version on the board is 2.12 . Will there be some operator incompatibility issues? Are there any incompatibility issues between higher and lower versions? Re: EIQ版本问题 Hello, Besides both version are not compatible, the operators need to be according to tensor flow. Regards
查看全文
IW61x: WCI2 and PTA external coexistence interfaces Dear NXP team, according IW611 / IW612 datasheets, these devices support both WCI-2 and PTA external coexistence interfaces. Does the latest firmware support both these features ? For IW612, PTA pins are the same used as SPI interface for 802.15.4 with OpenThread: how can PTA and SPI interface be simultaneously available ? Thanks Best Regards Pier Product: WiFi IW6XX Re: IW61x: WCI2 and PTA external coexistence interfaces Please use the latest firmware and driver. Tag lf-6.6.36-2.1.0. Regards, Daniel. Re: IW61x: WCI2 and PTA external coexistence interfaces Hi @DanielRuvalcaba, thanks for the update, this is a great news. Could you please share in which firmware release "External Coex" has been added ? Best Regards Pier Re: IW61x: WCI2 and PTA external coexistence interfaces Hi @pierluigi_p , I'm sorry for the inconvenience. After crosschecking internally, seems the release notes have a typo. IW61x does support external coexistence. I just raised a request to correct it. Regards Daniel. Re: IW61x: WCI2 and PTA external coexistence interfaces Hi @DanielRuvalcaba, thanks for pointing this out. Could you please also check if there's any plan to support it ? Best Regards Pier  Re: IW61x: WCI2 and PTA external coexistence interfaces Thanks for the info. The datasheet states “…when 802.15.4 is used, WCI-2 is the only interface available for coexistence with an external radio.” According to the NXP Wireless SoC Features and Release Notes for Linux, at this moment external coexistence is not supported for IW61x. Let me double check if we have something about this. Regards, Daniel. Re: IW61x: WCI2 and PTA external coexistence interfaces Hi @DanielRuvalcaba, we are planning to use NXP Yocto Scarthgap 2.0.0 with iMX8MP and both IW611 (Murata Type 2DL) and IW612 (Murata Type 2EL) depending on customers requirement. According NXP and Murata datasheets both the modules are suitable. Please let me know if you need further details. Thanks Best Regards Pier Re: IW61x: WCI2 and PTA external coexistence interfaces Hi, Could you please help me with the following information? - What host are you using? - OS version? - What module are you using for IW612? Regards, Daniel.
查看全文
MPC5744P ADC stop working in the field Hi, I hope someone can help me on this issue urgently. We have a product in the field where the ADC suddenly stop working and the value of ADC values are frozen. This issue only occurs in the field and we cannot replicate in test lab. I have consulted the processor Manual but couldn't find any source that could stop the ADC conversion without any warning. The ADC start working properly after the CPU is hard reset. We are also monitoring internal CPU temperature which shows the same behavior. Please could you explain what could be the source of this behavior?. is it possible to just restart the ADC module without hard rest to bring the ADC module back to life?. Thanks, Kind Regards, Ali Meraj General Re: MPC5744P ADC stop working in the field Hello, we've encountered a similar issue. Our chip is an MPC5675K, and we're using the ADC to collect data from three channels. However, at some point, the data stopped working simultaneously. We've tested our device in the lab for EFT, but haven't been able to replicate the issue. We're currently at a loss as to what to do about this sudden ADC freeze. Do you have any new solutions? Re: MPC5744P ADC stop working in the field Hi Peter, Sorry I wanted to mention that we can't restart. we have done some high resolution scope measurements and we are finding that when HV is turned ON the ADC input goes above 5V from couple of micro seconds before it is settled again. we are looking into this issue closely in the lab now and the Electronics team is working to mitigate this issue. I agree with all of your points. I will update you with some scope plots once I have them from the Lab and probably provide you more information of our findings. Thank you very much Peter. Regards, Ali Meraj Re: MPC5744P ADC stop working in the field Hi, The problem is that we can reset the Micro as these ADC fault doesnt effect the control but it limits the product functionality. You can or can't? Because there is only way how to reset ADC module and PBRIDGE(where the registers are located) and that is system reset. This is also outcome from my discussion with design. Furthermore, if you disturbing micro with EMI (900V switching) I assume that this is critical also for micro as whole concept. How you can guarantee the safety functions with such heavy disturbance which stops ADC module. Other modules can be affected as well, modules like FCCU, STCU, or similar which are not in use all the time micro is running. You just see only ADC issue as it is all the time running. In case you switch on high voltage in moment micro is processing some IVOR, or FCCU routine, it can have critical impact on system. These are just a few assumption from my side. regards, Peter Re: MPC5744P ADC stop working in the field Hi Peter, Thanks for testing. The problem is that we can reset the Micro as these ADC fault doesnt effect the control but it limits the product functionality. The products are already with the customer we can modify anything on those but we are doing internal investigation on how to minimize EMI effect on Mirco so that we revise our product. The interim fix would be to restart the ADC somehow to get them back online when the fault occurs on the existing products. so I think you are suggesting the only solution would be to reset the Mirco and there is no other way to bring the ADC back to life? would you suggest to first take the ADC into power down then disable the clock and then restart the clock and then restart the ADC do you think that would restart the ADC conversion again? Thank you very much Peter for your help. Kind Regards, Ali Meraj Re: MPC5744P ADC stop working in the field Hi, PCTLx will cut off the clocks to ADC. Refer to reference manual: 59.3.52   ADC_0 Peripheral Control Register (MC_ME_PCTL237) But I have just tested it and it will  not erase the ADC registers. (they are on PBRIDGE) so after restoring the clocks to ADC the registers value it the same. I guess only way to reset the ADC registers is to trigger reset of micro. What happen if you shield the ECU from EMI? Does the issue remain? regards, Peter Re: MPC5744P ADC stop working in the field Hi Peter, I took the ADC to power down by setting power down bit to 1 then wait till the ADC status is changed to power down then restart it. i have attached the code of ADC restart. I am using SCAN mode for normal conversion not CTU mode. so at the startup of the code the ADC is started once by setting NSTART bit to 1 and then just read the data from CDATA i have attached the code of ADC config and ADC read every 1ms I hope this explain how the ADC is setup. why would the conversion stop? this is random issue as it mostly happens when the high voltage (800V) supply is turned on. This issue is EMI related but its locking up the CDATA reg. how would i trigger the conversion again as I think in SCAN mode trigger is not required. the valid bit should be cleared when the data is extracted from CDR data but it doesn't clear when the CPU is in this state. you mention about PCTL register could you please provide more information on restarting the ADC using PCTL reg. Please let me know if you need more information. Regards, Ali Meraj Re: MPC5744P ADC stop working in the field Hi, The ADC module restart didn't solve the issue as the ADC values remain frozen even after trying to restart ADC module. How did you restart ADC module? Did you turn it of in PCTL register and then mode transition to RUNx and back? Could you please help me on understanding why the CDR reg is locking up?. It looks like the ADC conversion finished and new one is not started. (So the ADC is not stuck but staying in defined state and waiting for new conversion trigger, either SW or CTU) This I do not know as I have only limited information on how do you use ADC. regards, Peter PS: what happen if you start ADC conversion manually via debugger after it is stuck? Does it continue converting? Re: MPC5744P ADC stop working in the field Hi Peter, I hope you are doing good. I have an update The ADC module restart didn't solve the issue as the ADC values remain frozen even after trying to restart ADC module. I have register snapshots which give more insight of this issue. When this issue happens the ADC module is working normal and ADC Status is toggling between state  4 and 6 but the CDATA reg is frozen to a fix value CDR Registers so they all lock up to same value of 1171 decimal (0x493 Hex) and the Valid bit remains high The CPU and BandGap shows the same behavior. Could you please help me on understanding why the CDR reg is locking up?. Thanks, Kind Regards, Ali Meraj Re: MPC5744P ADC stop working in the field Ok Peter, thanks. I will log the ADC status and if i have an update I will get back to you. thanks, Ali Re: MPC5744P ADC stop working in the field Hard to say, I never tried it this way. But if the clock is lost you wont be able to read anything from registers on PBRIDGE where also ADC is. But as you are able to read results, I will suspect the ADC conversion is not in scan mode and it is IDLE. Re: MPC5744P ADC stop working in the field Hi Peter, I will try to save the ADC status in the flash when this fault occurs. if it is a clock issue then do you think that taking ADC into power down and restart will resume the clock? Regards, Ali Re: MPC5744P ADC stop working in the field Hmm, The most important is to see if the ADC is still converting but the result registers are not updated. Test SW should check the ADC status and store it when ADC conversion is stuck. As it is in scan mode, I guess only loss of clock can cause this condition. But first lets see if the ADC is still converting when the issue occurs. regards, Peter Re: MPC5744P ADC stop working in the field Hi Peter, The main problem is that I cant replicate the fault in the LAB so I am not sure what will be the status of the ADC status register in the field. I have prepared a test software to perform ADC reset if the ADC values are stuck so I am hoping that might get around this issue. what i have tried is taking the ADC supply below 3.3V but then MCU resets so that is not what is causing the issue as we don't see the CPU reset in the field. I have also tried changing the ADC ref voltage but this doesn't stop the ADC module from working. is there anyway I can force any particular issue on ADC hardware so that it gets stuck for example as you mentioned about loss of ADC calibration? I will check the FCCU for the fault reaction in case of voltage issue which i think is not configured to perform reset. Thanks, Ali Re: MPC5744P ADC stop working in the field Well, all this is hypothetical. If the ADC power drops or spikes out of LVD/HVD thresholds then the device will perform notification and reset if enabled. It can cause decalibration of ADC capacitors, or stuck on logic level, or many other things. What about enabling and disabling ADC? What is the Status of the ADC when it is stuck? regards, Peter Re: MPC5744P ADC stop working in the field Hi Peter, when this happens the counts are frozen to 1373 counts and never recover so we have to do power cycle. it mostly happens on HV power up but sometimes its random and it happens during the functional operation. We have tested the boards in HV lab and seen spikes on ADC_HV and ADC_ref when the HV is turned on but ADC doesn't stop working it only happens in field where I am assuming the EMI levels are high. The ADC_HV and ADC_ref voltage settles downs quite quickly after HV is on. Do you know any particular state that ADC takes itself in case of power failure or noise? does restarting ADC will help? Kind Regards, Ali Re: MPC5744P ADC stop working in the field ok, since it is only when you turn 900V on, them I suspect it can be EMI issue. What are the ADC voltages measurement when this happens? Are there any spikes on ADC ref or ADC_HV? What about measured line voltages? regards, Peter Re: MPC5744P ADC stop working in the field Hi Peter, thanks for reply. I am using SCAN mode @80Mhz clock rate. I start the conversion in the startup task which only execute once. I collect the converted data from CDATA reg whenever it is need by Application. we have our own control board which we are using for testing. This issue occurs when high voltage supply is turned on i.e.900Vdc. so it might be related to EMI but the ADC never recovers and counts reports 1373 counts constantly. This happens only in field as we cant replicate this issue in our HV lab. below is the code for ADC setup and reading Thanks, Ali ADC_0.MCR.B.OWREN = 1U; /* Enable result overwriting */ ADC_0.MCR.B.CTUEN = 0U; /* CTU mode not enable */ ADC_0.MCR.B.MODE = CDD_ADC_CONTINIOUS_SCAN_CONVERSION; ADC_0.MCR.B.ADCLKSEL = 1U; /* 80 Mhz mode */ ADC_0.MCR.B.PWDN = 0U; /* Enable ADC0 (release it from power-down mode) */ /* NSTART Should be the last register bit set */ ADC_0.MCR.B.NSTART = 1; /* Start normal mode */     READING of ADC converted DATA                                                                        Re: MPC5744P ADC stop working in the field Hi Ali, From the very brief description you have provided it can be anything from top level tasks handling trough  permission on buses down to the unserved ADC trigger or clock glitch. Maybe it would be a good start to tell us how do you use ADC (CTu or CPU mode?) How do you trigger conversion How do you serve converted data because it really looks like unserved corner case of your SW design. Is your SW running correctly on NXP EVB? regards, Peter Re: MPC5744P ADC stop working in the field Hi, Could someone help me on this issue please? Regards, Ali
查看全文
how much i set tempSense Voltage supply? i am using s32k344. i wanna use tempSense in mcu.  how much i set tempSense Voltage supply? if i set 0x15, is that mean is 1.5V? Re: how much i set tempSense Voltage supply? Hi@rlaxortn I have already answered all of these in your previous questions. if i set 0x15, is that mean is 1.5V?, the answer is yes, But this value is not set randomly. I suggest you read Chapter 85 Temperature Sensor in the data sheet .
查看全文
Register Protection for MPC5746C These are the Modules on which I am implementing Locking mechanism under Register Protection for MPC5746C.     0xFFFB0140, /* CMU------------*/     0xFFFB0040, /* FXOSC----------*/     0xFFFB0180, /* MC_CGM --------*/     0xFFFB8000, /* MC_ME ---------*/     0xFFFA8000, /* MC_RGM --------*/     0xFFF50000, /* MEMU_0 -------*/     0xFFFB0080, /* PLLDIG --------*/     0xFFFA0400, /* PMCDIG --------*/     0xFFFC0000, /* SIUL2 ---------*/     0xFFFB0100, /* SXOSC ---------*/     0xFFF9C000 /* LPU_CTL -------*/ Sample 1: (0xFFFB0000, offset - 0x4, 32-bit protection) Register: Matches ME_MCTL (mode control register, 32-bit protection, offset 0x4 per Table 77-5). Base Address: 0xFFFB0000. Protection Size: 32 bits (all four bytes are protected). Calculations Normal Address: base + offset = 0xFFFB0000 + 0x4 = 0xFFFB0004 Mirrored Address (Area 3): base + 0x2000 + offset = 0xFFFB0000 + 0x2000 + 0x4 = 0xFFFB2004 Soft Lock Bits Address (Area 4): Offset in Area 4: offset/4 = 0x4 / 4 = 0x1. Address: base + 0x3800 + offset/4 = 0xFFFB0000 + 0x3800 + 0x1 = 0xFFFB3801. For a 32-bit register, all four SLBs (SLB0–SLB3) control the four bytes (e.g., 0x4 to 0x7). Soft Locking Option 1: Write to Mirrored Address: Write a 32-bit value to 0xFFFB2004 (e.g., 0x80000000 to initiate a mode transition; refer to MC_ME chapter for valid values). This updates ME_MCTL at 0xFFFB0004 and sets SLB0–SLB3 in the SLBRn register at 0xFFFB3801. Example: *(volatile uint32_t *)0xFFFB2004 = 0x80000000; Option 2: Direct SLB Write: Write to 0xFFFB3801 to set SLB0–SLB3. Write 0xFF (WE0–WE3=1, SLB0–SLB3=1) to lock all four bytes. Example: *(volatile uint8_t *)0xFFFB3801 = 0xFF; Unlocking Write 0xF0 to 0xFFFB3801 (WE0–WE3=1, SLB0–SLB3=0) to clear SLB0–SLB3, unlocking the register. Example: *(volatile uint8_t *)0xFFFB3801 = 0xF0; Hard Locking Write 0x00000001 to 0xFFFB3FFC to set GCR.HLB, locking SLBs until reset. Example: *(volatile uint32_t *)0xFFFB3FFC = 0x00000001; Below in an example of register set whose all 4 address set are enable and can be R/W. Below in an example of register set whose Base + offset & Mirror addresses are enabled and can be R/W and other addresses can’t be set. This poses a serious issue as SLB bits confirms soft locking and GCR bits are set to implement hard lock. For All MC_CGM caped registers I can find the same problem. What could be the reason for these different behavior. Some addresses can be modified and changed other are reserved. Re: Register Protection for MPC5746C Hello, if I Hard lock any one module , all other modules are getting hard locked automatically, which raises issue in Low power mode. since I do not want FXOSC/SXOSC and CMU to be hard locked here. The register protection is applied Pbridge. And on the PBRIDGE is the MC_CGM module: Which have then mapped peripherals under MC_CGM. Looks like you will need to use SLB instead of HLB to solve this. As HLB will lock whole MC_CGM. Best regards, Peter Re: Register Protection for MPC5746C Hi Peter , Thank you for the help. I can configure Soft lock and monitor SLB for all modules now. I have another question regarding Hard Lock GCR bit. According to your explanation for all the MCCGM capped modules which are  CMU,FXOSC,SXOSC, PLLDIG and MCCGM shall have one common base address , that is 0xFFFB0000. now according to section 77.1.1 Register protection configuration, the NOTE talks about operations in Low power mode. As I said , having the same base address , if I Hard lock any one module , all other modules are getting hard locked automatically, which raises issue in Low power mode. since I do not want FXOSC/SXOSC and CMU to be hard locked here. is there any way around this problem. Thanks and regards Re: Register Protection for MPC5746C Hello, Here is the result of SLB for  CMU_LFREFR 32 -  addresses base and offset Base for CGM module is  0xFFFB_0000 CMU offset is 0x140 CGM LFREFR offset is 0x14C from module base I set SLB for CMU_LFREFR via write to mirror Best regards, Peter Re: Register Protection for MPC5746C Hi , This is also not working . CMU_LFREFR 32 Offset 0xCh Protected size - 16 (Bytes 2 and 3) 0xFFFB0000, /* CMU----------*/ Base address -0xFFFB000C Mirror address -0xFFFB200C SLB - 0xFFFB3803 GCR - 0xFFFB3FFC Re: Register Protection for MPC5746C Hello, Looking at simple test: MC_CMU - CSR Base Address - 0xFFFB014C - This is offset address. Not Base. Base for MC_CMU module is 0xFFFB 0140. Mirror Address -0xFFFB214C  Would be base +offset + mirror SLB -0xFFFB3943 Take as base address of whole CGM as present in ref manual: So calculations are: 0xFFFB0000 + 3800 + position of SLB GCR - 0xFFFB413C Same as above 0xFFFB0000+3FF0 Best regards, Peter Re: Register Protection for MPC5746C Hi Peter , here are some samples where SLB and GCR are not working.  can You please check this addresses and confirm if they show different behavior. if not then what could be the problem with these modules ? 1. MC_CMU -  0xFFFB0140 -  { MODULE_CMU, 0xC,REG_SIZE_16}, CMU_LFREFR Base Address - 0xFFFB014C Mirror Address -0xFFFB214C SLB -0xFFFB3943 GCR - 0xFFFB413C 2. MC_CMU -  0xFFFB0140   { MODULE_CMU, 0x18,REG_SIZE_32}, CMU_MDR Base Address - 0xFFFB0158 Mirror Address - 0xFFFB2158 SLB - 0xFFFB3946 GCR - 0xFFFB413C 3. PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x20, REG_SIZE_16}, PLLDIG_PLLCR Base Address - 0xFFFB00A0 Mirror Address - 0xFFFB20A0 SLB - 0xFFFB0F5D GCR - 0xFFFB407C 4. PLLDIG 0xFFFB0080 - { MODULE_PLLDIG, 0x28,REG_SIZE_32}, PLLDIG_PLLDV Base Address - 0xFFFB00A8 Mirror Address - 0xFFFB20A8 SLB - 0xFFFB388A GCR - 0xFFFB407C 5. PMCDIG 0xFFFA0400 - { MODULE_PMCDIG, 0x0,REG_SIZE_32}, Base Address - 0xFFFA0400 Mirror Address - 0xFFFA2400 SLB - 0xFFFA3C00 GCR - 0xFFFA43FC 6. PMCDIG 0xFFFA0400 -{ MODULE_PMCDIG, 0x10,REG_SIZE_32}, Base Address - 0xFFFA0410 Mirror Address - 0xFFFA2410 SLB - 0xFFFA3C04 GCR - 0xFFFA43FC Re: Register Protection for MPC5746C Hello, I have checked the PREG_PROT and it behave like described in reference manual: on ME_CGM register SC_DC0: Base :  0xFFFB0000 + Offset 7E8 Mirror: 0xFFFB07E8 = Base (0xFFFB0000) + Offset(7E8) + Mirror (0x2000) In the example I have locked the SC_DC0 form ME_CGM module by Soft lock. Here is the breakdown: Area 4:  is 1.5 KB and holds the Soft Lock Bits, one bit per byte in area 1. The four Soft Lock Bits associated with one module register  word are arranged at byte boundaries in the memory map. The Soft Lock Bit registers can be directly written using a bit mask. So you have to divide the area of Soft lock bits by 8 to see corresponding SLB settings. Base (of module) + 3800 + (one bit per byte of area 1) For Hard lock bit it is one for whole module. Area 5 is 512 bytes large and holds the configuration bits of the protection mode. There is one configuration hard lock bit per module that prevents all further modifications to the Soft Lock Bits and can only be cleared by a system reset once set. The other bits, if set, will allow user access to the protected module. Base (of module) 0xFFFB0000 + Offset 3FFC As GCR is at end of area 5. Best regards, Peter Re: Register Protection for MPC5746C Hello, I will test it and come back to you ASAP. Best regards, Peter
查看全文
9S12XDP512CAG-9S12XDT512CAA dump Address How to fill in Hi, I want to extract a FLASH&EEPROM backup from 9S12XDP512CAG and 9S12XDT512CAA. How should I enter the address in the USBDM memory dump Re: 9S12XDP512CAG-9S12XDT512CAA dump Address How to fill in Hi, It's ages since I've looked at this chip so the following is from a quick inspection of the manual. Refer to the memory map Figure 1-3. S12X CPU & BDM Global Address Mapping and boundaries in Table 1-2. Device Internal Resources. Linear address: [EEPROM_LOW to 0x13_FFFF] => [0x13_F000 to 0x13_FFFF] [FLASH_LOW to 0x7F_FFFF] => [0x78_0000 to 0x7F_FFFF] Attached is a config file to try. If loading with the HC12 programmer select linear image before loading the file. bye
查看全文
RW612 and Openthread function txpower Using the u-Blox IRIS-W106-10B (RW612) with MCUXpresso/Zephyr 4.2.0.  Most features work fine with openthread.  The device can get on mesh and ping, etc.  But some features are missing in software.  Using otPlatRadioSetTransmitPower() causes a reset, for example. Side note: The API should be support a signed int because, for example, -1 dBm is a valid setting. I noticed there is an example with vendor set tx power, which does not work after I port it in.  I think it should be hooked into the otPlatRadioSetTransmitPower() function. #define SPINEL_PROP_VENDOR_NXP_GET_SET_TXPOWERLIMIT_CMD (SPINEL_PROP_VENDOR__BEGIN + 0x10B) Also, perhaps related, getting the eui64 does not work.  I reworked the function to return the lower 8 bytes of the hwinfo address: hwinfo_get_device_id.  I suspect that this is probably not correct. Setting the Tx power from the C app is crucial for our application. Thanks Re: RW612 and Openthread function txpower Hello @joanou. I can infer that you are porting an OpenThead example to Zephyr, although please correct me if I'm wrong. As I mentioned before, I suggest that you take as reference and/or test the OpenThread Shell example from the Zephyr repository to check for additional porting details related to the transmit power control, which is included in this example. Please let me know if the example works for you. Re: RW612 and Openthread function txpower Hi, I am using the nxp_ot_cli sample with some of my customizations. Here is main() below.  I also added vendor hook for the SPINEL_PROP_VENDOR_NXP_GET_SET_TXPOWERLIMIT_CMD callback from spinel.  I added this for modules/openthread/platform/radio_spinel.cpp +otError otPlatRadioGetVendorMaxTransmitPower(otInstance *aInstance, uint8_t *aPower) +{ + otError error; + + OT_UNUSED_VARIABLE(aInstance); + + if (psRadioSpinel == NULL) + { + otLogWarnPlat("psRadioSpinel for max tx get is null"); + return OT_ERROR_GENERIC; + } + + VerifyOrExit(aPower != NULL, error = OT_ERROR_INVALID_ARGS); + error = psRadioSpinel->GetVendorMaxTransmitPower(*aPower); + +exit: + return error; +} + +otError otPlatRadioSetVendorMaxTransmitPower(otInstance *aInstance, uint8_t aPower) +{ + if (psRadioSpinel == NULL) + { + otLogWarnPlat("psRadioSpinel for set max Tx power is null"); + return OT_ERROR_GENERIC; + } + + OT_UNUSED_VARIABLE(aInstance); + return psRadioSpinel->SetVendorMaxTransmitPower(aPower); +} + The openthread module was modified to support hte vendor hook. modified: include/openthread/platform/radio.h modified: src/lib/spinel/CMakeLists.txt modified: src/lib/spinel/radio_spinel.cpp modified: src/lib/spinel/radio_spinel.hpp modified: src/lib/spinel/spinel.h modified: src/lib/spinel/spinel_driver.cpp This was added to spinel.h. SPINEL_PROP_VENDOR_NXP_GET_SET_TXPOWERLIMIT_CMD = (SPINEL_PROP_VENDOR__BEGIN + 0x10B),   int main(void) {    LOG_INF("nxp_ot_cli entry");    k_sleep(K_MSEC(500));    ot_context = openthread_get_default_context();    __ASSERT(ot_context != NULL, "Fatal: OpenThread context not available!");    ot_instance = openthread_get_default_instance();    __ASSERT(ot_instance != NULL, "Fatal: OpenThread instance not available!");    LOG_INF("Setting openthread leader weight");    otThreadSetLocalLeaderWeight(ot_instance, 2);    LOG_INF("Done setting leaderweight");    k_sleep(K_MSEC(500));    LOG_INF("Setting openthread radio max transmit power to 12/2 dBm ...");    otError err1 = otPlatRadioSetVendorMaxTransmitPower(ot_instance, 12);    LOG_INF("Set openthread radio max transmit power: %s (err=%d)", otThreadErrorToString(err1), err1);    k_sleep(K_MSEC(500));    uint8_t aPower = 0;    LOG_INF("Getting openthread radio transmit power ...");    otError err2 = otPlatRadioGetVendorMaxTransmitPower(ot_instance, &aPower);    if ((aPower % 2 == 0))    {       LOG_INF("Getting openthread radio transmit power is %u or %u.0 dBm, %s (err=%d)", aPower, aPower/2, otThreadErrorToString(err2), err2);    }    else    {       LOG_INF("Getting openthread radio transmit power is %u or %u.5 dBm, %s (err=%d)", aPower, aPower/2, otThreadErrorToString(err2), err2);    }    //LOG_INF("Loop now");    while (1)    {       LOG_INF("Loop now");       k_sleep(K_MSEC(1000));    }    return 0; } Re: RW612 and Openthread function txpower Hello @joanou, hope you are doing well. Are you doing your testings in a custom application or is it in any existing example? If it is an existing example what changes have you done? Additionally, could you please test the openthread "shell" example? The example provides an input command to change the transmission power. Please let me know whether this works for you or if you see a different behavior.
查看全文