Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
declaration of a LCU function I am trying to generate complimentry PWM using eMIOS and LCU. but upon building the project, the implicit declaration of a function error is coming when using the Lcu_Ip_SetSyncOutputEnable() although i have properly included the Lcu_Ip header file. No erro is coming when using the Lcu_Ip_Init() function. What is the cause of this error and how can it be solved ?? I have attached the project for reference, I am working on S32K3x4 - T172 board. Re: declaration of a LCU function Hi @sagar991  To be able to use the function Lcu_Ip_SetSyncOutputEnable() is required to enable the LCU SYNC functions in Config Tools.  B.R. VaneB
查看全文
PWM module does not want to access the custom interrupt routine but always jumps to the default rout Hi there, I am working with the FRDM-MCXA153 board. I´m trying to get an interruot on every rising edge using the standart PWM example portet to c++. So far so simpe, bit unfortunately the interrupt always wants to jump tot the standart interrupt routine (declared as WEAK) and ignores my self-written one. The PWM module is configured via ConfigTools -> Peripherals -> FLEXPWM0 and should generate an interrupt at VAL2. Thanks in advance for your help. MCXA Re: PWM module does not want to access the custom interrupt routine but always jumps to the default Hi, if your main-file is written in c++, you need to add extern "C" before your ISR. Following is a short text I found in the startup file: //***************************************************************************** // Forward declaration of the core exception handlers. // When the application defines a handler (with the same name), this will // automatically take precedence over these weak definitions. // If your application is a C++ one, then any interrupt handlers defined // in C++ files within in your main application will need to have C linkage // rather than C++ linkage. To do this, make sure that you are using extern "C" // { .... } around the interrupt handler within your main application code. //*****************************************************************************
查看全文
Want to isolate LPC55S36 on EVSE-SIG-BRD2X board and work on Lumissil CG5317 Hi team, I am working on EVSE-SIG-BRD2X board, where I want to isolate LPC55S36 chip on the board and work only on Lumissil CG5317. I have two EVSE-SIG-BRD2X boards, one I use it as EVSE and the other one as EV I actually want to test EV - EVSE high level communication between the two boards via Ethernet - PLC bridge So, I have my ISO 15118-2 software stack for both EVSE and EV I will run my EVSE software on one side on a Linux platform and EV software the other side on a Linux software This will establish a client(EV) - server(EVSE) High level communication My circuit is like the below one: PC <---> Ethernet <---> EVSE-SIG-BRD2X( EVSE ) <----> CP,PP <---> EVSE-SIG-BRD2X( EV )<--->Ethernet <---> PC The CP and PP pins facilitate communication between EV and EVSE via power line communication (PLC) I have gone through the below documents to understand and implement 1. UG10140 - EVSE-SIG-BRD2X Board User Guide 2. UM12128 - EVSE-SIG-BRD2X User Manual 3. X-EVSE-SIG-BRD2X Please let me know if any further information is required. Looking forward for your kind response and support Thanks in advance Regards, Somesh Re: EVSE-SIG-BRD2X board bring-up Hi team, I am working on  EasyEVSE EV Charging Signal Board (EVSE-SIG-BRD) with imx93 FRDM dev board  I have followed GitHub - nxp-imx-support/meta-imx-frdm: Yocto layer for i.MX FRDM boards to build the yocto image for imx93 frdm I added meta-nxp-easyevse-mpu (GitHub - nxp-imx-support/meta-nxp-easyevse-mpu: Easy EVSE MPU Yocto Layers)in the directory imx93_yocto_bsp/sources/ and also added in bblayers.conf  now I am facing issue of patch error (below): psti_ubuntu@pstiubuntu-Precision-Tower-7810:/media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/conf$ bitbake imx-image-full Loading cache: 100% |#################################################################################################| Time: 0:00:04 Loaded 8389 entries from dependency cache. Parsing recipes: 100% |###############################################################################################| Time: 0:00:02 Parsing of 5792 .bb files complete (5788 cached, 4 parsed). 8393 targets, 520 skipped, 18 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "2.8.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "aarch64-poky-linux" MACHINE = "imx93frdm" DISTRO = "fsl-imx-xwayland" DISTRO_VERSION = "6.6-scarthgap" TUNE_FEATURES = "aarch64 armv8a crc crypto" TARGET_FPU = "" DISTRO_NAME = "NXP i.MX Release Distro" ROS_DISTRO = "humble" ROS_VERSION = "2" ROS_PYTHON_VERSION = "3" meta meta-poky = "HEAD:f43f393ef0246b7bee6eed8bcf8271cf2b8cdf40" meta-oe meta-multimedia meta-python = "HEAD:80e01188fa822d87d301ee71973c462d7a865493" meta-freescale = "HEAD:0f8091c63dd8805610c09b08409bc58492a3b16f" meta-freescale-3rdparty = "HEAD:6c063450d464eb2f380443c7d9af1b94ce9b9d75" meta-freescale-distro = "HEAD:b9d6a5d9931922558046d230c1f5f4ef6ee72345" meta-imx-bsp meta-imx-sdk meta-imx-ml meta-imx-v2x = "HEAD:7c10a9c047ce8c1fde05c14ec4baf275bc232a57" meta-nxp-demo-experience = "HEAD:8fd7154c05b716e9635279047f65785399432d88" meta-nxp-matter-baseline meta-nxp-openthread = "HEAD:783becb4b5716d989f50db95b7133d38eae5b47b" meta-arm meta-arm-toolchain = "HEAD:1b85bbb4cab9658da3cd926c62038b8559c5c64e" meta-clang = "HEAD:fe561f41aef0cff9e6f96730ab59f28dca2eb682" meta-gnome meta-networking meta-filesystems = "HEAD:80e01188fa822d87d301ee71973c462d7a865493" meta-qt6 = "HEAD:dc13e1bfda4a4757a08c2d6673bc4bac012c4a80" meta-parsec meta-tpm = "HEAD:11ea91192d43d7c2b0b95a93aa63ca7e73e38034" meta-virtualization = "HEAD:6a80f140e387621f62964209a2e07d3bcfb125ce" meta-nxp-easyevse-mpu = "release/easyevse-mpu-2.0:7a106473ee10383b1fcd8d8491d8237ede6c2f38" meta-ros2-humble meta-ros-common meta-ros2 = "master:5fefe7f3c9e733321cb1786539a8c9c7571294cf" meta-imx-bsp meta-nxp-demo-experience = "lf-6.6.36-2.1.0:1377d9d8c658fd78f2a7362e09a75f5c929ff5ce" Sstate summary: Wanted 3675 Local 15 Mirrors 0 Missed 3660 Current 3706 (0% match, 50% complete)############ | ETA: 0:00:01 Removing 683 stale sstate objects for arch imx93frdm: 100% |##########################################################| Time: 0:00:11 Removing 5 stale sstate objects for arch x86_64: 100% |###############################################################| Time: 0:00:00 Removing 2165 stale sstate objects for arch armv8a: 100% |############################################################| Time: 0:00:15 NOTE: Executing Tasks ERROR: linux-imx-6.6.36+git-r0 do_patch: Could not apply patches for imx93frdm. ERROR: linux-imx-6.6.36+git-r0 do_patch: Patch failures can be resolved in the linux source directory /media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/tmp/work/imx93frdm-poky-linux/linux-imx/6.6.36+git/git) ERROR: linux-imx-6.6.36+git-r0 do_patch: ExecutionError('/media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/tmp/work/imx93frdm-poky-linux/linux-imx/6.6.36+git/temp/run.do_patch.128119', 1, None, None) ERROR: Logfile of failure stored in: /media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/tmp/work/imx93frdm-poky-linux/linux-imx/6.6.36+git/temp/log.do_patch.128119 Log data follows: | DEBUG: Executing python function extend_recipe_sysroot | NOTE: Direct dependencies are ['/media/psti_ubuntu/VolumeE/imx93_yocto_bsp/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', '/media/psti_ubuntu/VolumeE/imx93_yocto_bsp/sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/media/psti_ubuntu/VolumeE/imx93_yocto_bsp/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot'] | NOTE: Installed into sysroot: [] | NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'cmake-native', 'libtool-native', 'quilt-native', 'texinfo-dummy-native', 'kern-tools-native', 'openssl-native', 'expat-native', 'ncurses-native', 'zlib-native', 'git-native', 'make-native', 'patch-native', 'perl-native', 'bzip2-native', 'xz-native', 'zstd-native', 'attr-native', 'ca-certificates-native', 'curl-native', 'gdbm-native'] | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_patch | (1/45) 0001-gpio-pca953x-fix-pca953x_irq_bus_sync_unlock-race.patch | (2/45) 0002-arm64-dts-add-i.MX93-11x11-FRDM-basic-support.patch | (3/45) 0003-arm64-dts-add-imx93-11x11-frdm-mt9m114-dts.patch | (4/45) 0004-Add-DSI-Panel-for-imx93.patch | (5/45) 0005-Add-CTP-support-for-waveshare-panel.patch | (6/45) 0006-arm64-dts-add-imx93-11x11-frdm-tianma-wvga-panel-dts.patch | (7/45) 0007-arm64-dts-add-imx93-11x11-frdm-aud-hat-dts.patch | (8/45) 0008-arm64-dts-add-button-support.patch | (9/45) 0009-arm64-dts-add-imx93-11x11-frdm-ov5640-dts.patch | (10/45) 0010-arm64-dts-add-imx93-11x11-frdm-ld.dts-for-lpm.patch | (11/45) 0011-arm64-dts-add-pwm-function-of-the-LED.patch | (12/45) 0012-arm64-dts-add-imx93-11x11-frdm-8mic.dts.patch | (13/45) 0013-arm64-dts-add-imx93-11x11-frdm-lpuart.dts.patch | (14/45) 0014-arm64-dts-add-imx91-frdm-dts-files.patch | (15/45) 0015-arm64-dts-add-imx91-11x11-frdm-tianma-wvga-panel-dts.patch | (16/45) 0016-arm64-dts-add-imx91-11x11-frdm-mt9m114.dts.patch | (17/45) 0017-arm64-dts-add-imx91-11x11-frdm-aud-hat-dts.patch | (18/45) 0018-arm64-dts-add-imx91-11x11-frdm-8mic.dts-and-fix-imx9.patch | (19/45) 0019-arm64-dts-add-imx91-11x11-frdm-lpuart.dts.patch | (20/45) 0020-LF-13459-clk-imx-Fix-the-pll-power-up-flow.patch | (21/45) 0021-thermal-imx91-bug-fix-Temperature-read-returns-Resou.patch | (22/45) 0022-LF-14498-arm64-dts-imx91-Correct-ENET1_TD3-and-I2C2_.patch | (23/45) 0023-arm64-dts-Add-i.MX8MP-FRDM-board-support.patch | (24/45) 0024-arm64-dts-add-os08a20-device-node-for-i.MX8MP-FRDM-b.patch | (25/45) 0025-arm64-dts-add-dual-BOE-EV121WXM-N10-1850-LVDS-panel-.patch | (26/45) 0026-arm64-dts-imx8mp-frdm-add-dual-os08a20-sensors-for-i.patch | (27/45) 0027-arm64-dts-imx8mp-frdm-add-AP1302-support.patch | (28/45) 0028-arm64-dts-imx8mp-frdm-add-dual-AP1302-support.patch | (29/45) 0029-arm64-dts-imx8mp-frdm-add-imx8mp-frdm-8mic.dts.patch | (30/45) 0030-arm64-dts-imx8mp-frdm-enable-7inch-waveshare-panel.patch | (31/45) 0031-arm64-dts-imx8mp-frdm-add-imx8mp-frdm-rpmsg.dts.patch | (32/45) 0032-arm64-dts-imx8mp-frdm-using-green-led-instead-of-blu.patch | (33/45) 0033-arm64-dts-imx8mp-frdm-fix-wifi-reset-pin.patch | (34/45) 0034-arm64-dts-imx8mp-frdm-clean-imx8mp-frdm.dts.patch | (35/45) 0035-arm64-dts-imx8mp-frdm-fix-interrupt-pin-in-imx8mp-fr.patch | (36/45) 0036-Revert-commit-e85faa36ec41d8304a4f0123d6152274595f1e.patch | (37/45) 0037-arm64-dts-imx8mp-frdm-add-AP1302-support-instead-of-.patch | (38/45) 0038-arm64-dts-imx8mp-frdm-add-rpmsg-audio-support.patch | (39/45) 0039-drm-panel-panel-waveshare-dsi-Add-bridge-and-connect.patch | (40/45) 0040-arm64-dts-imx8mp-frdm-update-waveshare-panel-node.patch | (41/45) 0041-drm-panel-remove-wavesahre-node-in-simple-panel.patch | (42/45) 0042-arm64-dts-imx8mp-frdm-add-imx8mp-frdm-iw612-otbr-dts.patch | (43/45) 0001-EasyEVSE-LF6.1.36-DTS-support-for-i.MX8MNLPDDR4-and-.patch | [INFO]: check of .kernel-meta//patches//./0001-EasyEVSE-LF6.1.36-DTS-support-for-i.MX8MNLPDDR4-and-.patch with "git am" did not pass, trying reduced context. | [INFO]: Context reduced git-am of .kernel-meta//patches//./0001-EasyEVSE-LF6.1.36-DTS-support-for-i.MX8MNLPDDR4-and-.patch with "git am" did not work, trying "apply". | /media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/tmp/work/imx93frdm-poky-linux/linux-imx/6.6.36+git/git/.git/rebase-apply/patch:52: trailing whitespace. | pinctrl-2 = <&pinctrl_cg5317>; | /media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/tmp/work/imx93frdm-poky-linux/linux-imx/6.6.36+git/git/.git/rebase-apply/patch:328: trailing whitespace. | }; | error: patch failed: arch/arm64/boot/dts/freescale/Makefile:377 | error: arch/arm64/boot/dts/freescale/Makefile: patch does not apply | [ERROR]: Application of .kernel-meta//patches//./0001-EasyEVSE-LF6.1.36-DTS-support-for-i.MX8MNLPDDR4-and-.patch failed. | Patch needs to be refreshed. Sample resolution script: | .git/rebase-apply/resolve_rejects | ERROR: Could not apply patches for imx93frdm. | ERROR: Patch failures can be resolved in the linux source directory /media/psti_ubuntu/VolumeE/imx93_yocto_bsp/frdm-imx93/tmp/work/imx93frdm-poky-linux/linux-imx/6.6.36+git/git) | WARNING: exit code 1 from a shell command. ERROR: Task (/media/psti_ubuntu/VolumeE/imx93_yocto_bsp/sources/meta-imx/meta-imx-bsp/recipes-kernel/linux/linux-imx_6.6.bb:do_patch) failed with exit code '1' NOTE: Tasks Summary: Attempted 7863 tasks of which 7842 didn't need to be rerun and 1 failed. Summary: 1 task failed: /media/psti_ubuntu/VolumeE/imx93_yocto_bsp/sources/meta-imx/meta-imx-bsp/recipes-kernel/linux/linux-imx_6.6.bb:do_patch Summary: There were 3 ERROR messages, returning a non-zero exit code. Looking forward for your kind response and help Thanks in advance. Regards, somesh Re: EVSE-SIG-BRD2X board bring-up Hello, The EVSE Kit for MPU is using i.MX93. You can refer the documents in EVSE page. https://www.nxp.com/design/design-center/development-boards-and-designs/EV-CHRG-STN-MPU If you want to verify it on i.MX8MM, i think you need modify lots of source code to make it work on i.MX8MM based on the Getting Started with the EasyEVSE Development Platform here. https://www.nxp.com/document/guide/getting-started-with-the-easyevse-development-platform-linux-os-wi-fi-6:GS-EV-CHRG-STN-MPU?section=get-software Best Regards, Zhiming EVSE-SIG-BRD2X board bring-up Hi Hope you are doing well! I want to use MII host interface of CG5317 for connection with host MPU (nxp i.MX 8M Mini) my question is 1. How can I achieve this communication using MII host interface? 2. Does the CG5317 chip on EVSE-SIG-BRD2X has firmware already flashed in it? 3. I connected RJ45 port to my host MPU (nxp i.MX 8M Mini) with ethernet but not able to detect the mac address or ip address from my host terminal I have attached screenshots and images of my circuit for your kind reference Regards, somesh Re: Want to isolate LPC55S36 on EVSE-SIG-BRD2X board and work on Lumissil CG5317 Hello, If you only want to test Lumissil CG5317, please use Lumissil CG5317 official board. If you want to only test CG5317 on EVSE-SIG-BRD2X board, you need to do hardware rework and we can't make sure that you can control CG5317 after rework. Best Regards, Zhiming
查看全文
Difference between MPL3115A2 and MPL3115A2S Hello, I am wondering what is the difference between MPL3115A2 and MPL3115A2S I can't tell why there is a change in reference as the datasheet seems identical. Thanks in advance, Re: Difference between MPL3115A2 and MPL3115A2S Dear CL_ENVEA, yes, this is correct. It is the same component. Thank you for posting the answer here, for other customer's convinience. With Best Regards, Jozef Re: Difference between MPL3115A2 and MPL3115A2S I got a quick reply from the tech support: 100% compatible, just a new fab
查看全文
siul2_port configuration and functional Group setting in s32ds 3.6 i wanna make each port container(adc, pwm, can, uart and so on) but i got a error about functional Group.  error is there are some duplicated 'NAME' in the PortContainer.  when i write a other PortContainer, portpin Mode, level value, slew Rate is not read. and i get errors. 1. is it imppssible for making multi portcontainer? 2. if it is possible, how it make that? 3. can i get codument or description for setting functional group and adding functional group? thanks for regards. General Re: siul2_port configuration and functional Group setting in s32ds 3.6 Please refer to the introduction in  Interacting with Digital Inputs/Outputs on MR-CANHUBK344  I have added the portpin id 1,2,3,4 in container 0. Re: siul2_port configuration and functional Group setting in s32ds 3.6 @Robin_Shen  i have questions.  1. what is mean portpin id//? portpin id is 5 in your post.  @Robin_Shen  what is meaning portpin id is 5 in your pic? does container 0 already has portpin id 1,2,3,4? exactly i don't know portpin id's meaning. is that just index? 2. if i have assign all of pin in one container, is it has a problem?  why s32ds has a continer? for managing pins??? thanks for regards Re: siul2_port configuration and functional Group setting in s32ds 3.6 Hi Did you add another PortContainer in Pins Tool? I'm not sure if this is what you need. If not please let me know. 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. -------------------------------------------------------------------------------
查看全文
[S32K3XX] C40_Ip using for accessing Code flash memory patition Hi. I am developing flash access using C40_Ip api in bootloader. Data memory partition(0x10000000) can be accessed by that API. But code memory partition(0x500000 ~ 0x007FE000) can not be accessed. Hard fault assert is happened.  C40_Ip API is located in SRAM like below. Could you give me some guide or hint for this debugging? Thank you in advance. Re: [S32K3XX] C40_Ip using for accessing Code flash memory patition Yes. It's work normally Re: [S32K3XX] C40_Ip using for accessing Code flash memory patition Hi@Changhawn Is your problem solved? I see that you have already set your answer as a solution. Re: [S32K3XX] C40_Ip using for accessing Code flash memory patition Basic working is confirmed. My access region is not wrong. Re: [S32K3XX] C40_Ip using for accessing Code flash memory patition I encountered the same problem as you. When writing to the PFLASH, a hardware fault occurred. Could you please tell me how you solved it?
查看全文
GPIO intentional shutdown Can I shutdown a Flexcomm I2C connection, then reuse the SCL and SDA pins for another purpose? LPC55xx Re: GPIO intentional shutdown Thank you, Alice Re: GPIO intentional shutdown Hello @Bill6  Yes, you can reuse them as normal gpio. BR Alice
查看全文
哪些 RTD 版本支持 S32K312 平台中的 SafeRTOS 示例代码? 我们知道它支持 FreeRTOS 并且还有开发示例代码,但我们认为应用程序的安全性更高。您计划何时提供 SafeRTOS 示例代码?可以运行哪些 RTD 版本。谢谢。
查看全文
Unable to flash i.MX1052 using MCUXpresso GUI Flash Tool. Hi! I am working with a custom board developed from the standard MIMXRT1050-EVKB with a RT1052 and a Windbond W25Q512JV. I tried flashing the SDK example flashloader onto my flash with two custom pin configurations that should boot up the LCD monitor on my board, using the GUI Flash tool. While the tool runs successfully without error, it seems that the tool didnt actually flash any image into the flash. The console log is as below: ----------------------------------------- P&E GDB Server for Arm(R) devices, Version 9.33.00.00 Copyright 2018, P&E Microcomputer Systems Inc, All rights reserved Loading library C:\nxp\MCUXpressoIDE_11.8.1_1197\ide\plugins\com.pemicro.debug.gdbjtag.pne_5.7.3.202310061729\win32\gdi\unit_ngs_arm_internal.dll ... Done. Command line arguments: -interface=USBMULTILINK -port=USB1 -speed=5000 -flashobjectfile=C:\Users\ \Documents\MCUXpressoIDE_11.8.1_1197\workspace\evkbimxrt1050_flashloader\Debug\evkbimxrt1050_flashloader.axf -device=NXP_iMX_IMXRT1052 -programmingtype=0 -runafterprogramming -startserver -singlesession -quitafterprogramming Device selected is NXP_iMX_IMXRT1052 User Specified Hardware Selection : Interface=USBMULTILINK and Port=USB1 Connecting to target. Unable to load libusb0.dll PEmicro Interface detected - Flash Version 11.22 Device is NXP_iMX_IMXRT1052. Mode is In-Circuit Debug. (C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com) API version is 101 TARGET XML PATH is C:\nxp\MCUXpressoIDE_11.8.1_1197\ide\plugins\com.pemicro.debug.gdbjtag.pne_5.7.3.202310061729\supportFiles_ARM\target_v7m_vfp.xml Server 1 running on 127.0.0.1:7224 Server 2 running on 127.0.0.1:7226 Server 3 running on 127.0.0.1:7228 Server 4 running on 127.0.0.1:7230 Server 5 running on 127.0.0.1:7232 Server 6 running on 127.0.0.1:7234 Server 7 running on 127.0.0.1:7236 Server 8 running on 127.0.0.1:7238 Server 9 running on 127.0.0.1:7240 Server 10 running on 127.0.0.1:7242 All Servers Running Target Disconnected. ----------------------------------------- It seems like the tool just terminated without doing anything. I customised two GPIO pins to output on the LCD. It can be switched on without any error during debugging, with the rest of the build identical to the SDK example. I have built a custom .cfx with the correct flash device configurations and QE_bit_config. I am also using an .arp for the flash that is unavailable in the IDE. Debugging SDK example flexspi_nor_polling_transfer is also successful. I understand that using MCUBootUtility is a more simple way to flash but both USB-HID and UART are unavailable options for my board. I only have the option of JTAG through a P&E USB UNIVERSAL FX.  I tried both flashing when the board was boot as serial downloader and internal boot, and tried to boot the board in internal boot mode to see if the LCD is switched on. Is there any flash specific configurations that I still need to alter to make this tool work? Is there any alternative way for flashing?  Thank you. Re: Unable to flash i.MX1052 using MCUXpresso GUI Flash Tool. Thank you for your reply. My colleague just made it work yesterday using Keil and J-link, while I have made very little progress using my set up for the past week. It feels like MCUXpresso's unique toolset still lacks much support and examples in documentations and drivers, but that may just be my lack of experience with this tool. Thank you for your help once again. Kin Re: Unable to flash i.MX1052 using MCUXpresso GUI Flash Tool. Hi @KinC  It seems like you’re dealing with a complex issue involving custom configurations and potential tool limitations. Here are a few things you can check or try to resolve the flashing problem: 1. Verify .arp and .cfx File Configurations: • Ensure that the .arp file you’re using correctly supports the Winbond W25Q512JV flash. Sometimes, custom .arp files might not fully align with the specific requirements of your flash memory or the RT1052. Double-check the configurations, especially the Quad Enable (QE) bit settings. 2. Review Pin Muxing: • Confirm that the custom GPIO pin configurations for the LCD do not conflict with the FLEXSPI pin configurations. Incorrect pin muxing could prevent the flash from being correctly accessed. 3. Check FLEXSPI Settings: • Review the FLEXSPI configuration in your flashloader project to ensure that the settings match the requirements of the W25Q512JV. Incorrect timing or command settings could lead to failed programming. 4. Alternative Flashing Method: • Since you have confirmed that MCUBootUtility is not an option, you can try using the J-Flash tool by SEGGER, which is another robust tool for programming external flash memories. If you have access to a J-Link debugger, you could try this approach. 5. Test with Another Flash Algorithm: • If you suspect the current flash algorithm is not working as expected, try experimenting with other compatible flash algorithms or tweaking the existing one to better suit your setup. 6. Double-Check Boot Mode: • Ensure that the board is correctly configured in the desired boot mode before flashing. This might involve setting specific boot pins or jumpers to ensure the MCU is in the correct state to accept programming. Hope this will help you. BR Hang Re: Unable to flash i.MX1052 using MCUXpresso GUI Flash Tool. Additional Info: I noticed that the Flash tool used  MCUXpressoIDE_11.8.1_1197\ide\plugins\com.pemicro.debug.gdbjtag.pne_5.7.3.202310061729\supportFiles_ARM\target_v7m_vfp instead of my provided .arp to flash the image. Although I have already configured the debug configuration to use my dedicated .arp. The dedicated .arp file will be used to erase the flash memory if I use the GUI Flash tool's 'Erase' function, but it won't use it to flash, which is confusing.  
查看全文
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; }; };
查看全文
SE050:缶n.c.ピンはグランドに接続されていますか? こんにちは SE050について: N.C.(未接続)のピンは全てVss(グランド)に接続できますか? データシートには明記されておらず、評価ボード上で浮いたままになっているため、質問する必要があります。 私のデザインは浮遊金属を必要としません。
查看全文
SJA1110 端口 2 PHY 至 MAC 你好, 我有一个 SJA1110,通过 SPI 和 RMII 连接到外部微控制器。 设法通过 SPI 配置上传使交换机工作。 看来,微控制器能够使用 RMII 接口,我可以将 MII_PHYSID1 和 MII_PHYSID2 读出为 0x001BB012。 但是,无论我做什么,都无法使链接状态变为“启动”。PHY 通过以太网电缆连接到我的计算机。 在编写了非常大的手册之后,我仍然不清楚是否需要以任何特殊方式配置端口 2 PHY 以便与 RMII 接口一起使用。 是否存在需要禁用的某种断电功能? 有人知道,一般程序是否与 TJA1100 相当? 谢谢! 回复:SJA1110 端口 2 PHY 至 MAC 现在可以了。RGMII Tx 时钟由外部 CPU 生成,固件中选择了错误的时钟源。将其设置为正确配置的时钟源,使以太网适用于 rx 和 tx。
查看全文
Issue with BMS SDK Version Hello everyone, I’ve been working with the SW32K344_HVBMS-RD_Bring-up_Example_S32DS_1_0_2_D2401 using BMS SDK version 1.0.2, and everything worked as expected. However, when I tried to use the latest version SW32K344_HVBMS-RD_Bring-up_Example_S32DS_1_0_3_D2408 with BMS SDK 1.0.3, I updated all the dependencies to version 1.0.3 and RTD 3.0.0. Despite everything appearing to be the correct version, the project fails to build. I’ve attached a picture showing the results. Has anyone else encountered this issue or have any suggestions on how to resolve it? Thank you! Re: Issue with BMS SDK Version Yes, the normal way , that's what I have did too. Re: Issue with BMS SDK Version Here is how I import the downloaded example: Re: Issue with BMS SDK Version Hello Robin, It’s quite strange how you resolved your issue, it doesn’t make much sense. Interestingly, my solution was very different. I had to move the example I downloaded from the generated bundle to the workspace of S32DS, and it worked! 😄 Could you please pass our issue to the concerned team? Maybe they can update to prevent similar issues in the future. Thank you! Re: Issue with BMS SDK Version Since a complete installation takes a lot of time, I just installed the installation packages you mentioned before on the basis of S32DS v3.5 + S32K3 RTD 3.0.0. After re-importing HvBms400_775_722_TPL_Bring_Up today, an error occurred when I clicked Update Code, which caused a build error. But when I reopened the S32 Configuration Tool and clicked Update Code again, Build Finished. 0 errors. Re: Issue with BMS SDK Version Hi @Robin_Shen  Could you give me the project to build my setup? It seems that I installed everything correctly,  I reinstalled S32DS and all of the packages, and still doesn’t work. What’s weird is that when I do this with version 1.0.2, it works, but when I reinstall everything with version 1.0.3, it doesn’t. Thank you. Re: Issue with BMS SDK Version Hi My Build Finished. 0 errors.  How did you install SW32K3_RTD_4.4_R21-11_3.0.0_D2303? Please install it by refer to HOWTO: offline install S32K3 RTD 3.0.0 in S32DS v3.5 Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" 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. -------------------------------------------------------------------------------
查看全文
"Flash_VerifyErase" does not work on PRINCE regions I have been using Flash_VerifyErase() to ensure I do not read an erased flash page and cause a hard fault. This has been working reliably until I turned on PRINCE flash encryption. For some reason, Flash_VerifyErase() does not detect an erased region of PRINCE flash and causes a hard fault when I perform a read. The function Flash_read() does not appear to work, so as it stands I do not have a way to ensure I do not hard fault while reading Flash. Is there a different function for detecting PRINCE erase? How can I prevent hard faulting when PRINCE is enabled? Re: "Flash_VerifyErase" does not work on PRINCE regions I have the same problem. How can I safely read an encrypted flash page? Re: "Flash_VerifyErase" does not work on PRINCE regions Yes, this is for the LPC55S69, version 1B silicon - sorry I forgot that information before! Please see my code, attached below. The commented portion is the recommended way to do Flash reads, but this section of code no longer works when PRINCE is enabled. Before I enabled PRINCE, I had this commented block inside the "else if" where the memcpy now lives. status_t status = FLASH_VerifyErase(&flash_instance, addr, PflashPageSize); if(status == kStatus_Success) { memset(data, 0xFF, len); return len; } else if(status == kStatus_FLASH_CommandFailure) { memcpy(data, (void*)addr, len); } else { return -1; } // status = FLASH_Read(&flash_instance, addr, data, len); // // if(status == kStatus_FLASH_EccError) // { // memset(data, 0xFF, len); // return len; // } // else if(status != kStatus_Success) // { // return -1; // } Re: "Flash_VerifyErase" does not work on PRINCE regions Hi, Alexander, Can you tell us the part number you are using? Do you use LPC55xx family? Anyway, I suggest you refer to AN12527.pdf and AN12527SW.zip which can be downloaded from the following link: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc5500-cortex-m33/high-efficiency-arm-cortex-m33-based-microcontroller-family:LPC55S6x?tab=Documentation_Tab If you still have issue, pls post all your code so that we can have a review. BR Xiangjun Rong
查看全文
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
查看全文
KW45 - LPSPI with DMA Hi all, I'm trying to implement simplex SPI transmissions with the KW45B41Z-EVK evaluation board. My goal is to perform fast SPI transmissions with DMA. The end goal is to drive an ILI9341 LCD display via the LPSPI1 peripheral. The problem I face is that the SPI transaction length is longer than specified in software. When I try to transmit 4 bytes, there are 12 bytes on the bus. When I try to transmit 64 bytes, there are 72 bytes on the bus. What I found is that there are always 8 more bytes transmitted than I intend to transmit. This appears to be related to the 'bits per frame' field, which I had set to 8 previously. Changing it to 16, I see that there are always 16 more bytes transmitted on the bus than there should be. This, of course, causes buffer overflows.  These same symptoms can be reproduced with both the  LPSPI_MasterTransferEDMALite() and the  LPSPI_MasterTransferEDMA() functions. The debugger shows that the bytesPerFrame value is 1, and therefore, I meet the conditions specified in the documentation. I require help resolving this buffer overflow. I've attached the project directory, as Bringup_LPSPI_eDMA.zip Thanks, Arush Re: KW45 - LPSPI with DMA Hello, Could you help us confirm if the peripherals tool you are referring is the one in MCUXpresso Config Tools? For more information about this tool and the workflow for MCUXpresso please refer to [MCUXIDECTUG] chapter 5 and 5.3.  On this guide you could see the peripherals configuration Please consider we do not recommend the usage of ConfigTools with the Wireless examples, as it could overwrite previous configurations needed for the wireless part. Hope this help you! Best Regards Luis Re: KW45 - LPSPI with DMA Hello, I'm referring to the following example: [kw45b41zevk_lpspi_edma_b2b_transfer_master]. Both the example, and my own project, are on SDK version 25.06.00(890 2025-06-27) I don't have a second EVK. I have been testing with an oscilloscope. These tests have been valid for blocking SPI transactions on this board, as well as past experience with different MCUs. The example project does work correctly, it transmits exactly 64 bytes, as specified by the TRANSFER_SIZE macro. In my project, I'm doing all the peripheral configurations via the peripherals configuration tool. The initialization code is auto-generated by that tool, and runtime code follows the example's logic. I suspect the flaw is somewhere in here, but I can't quite find it. As an aside; the peripherals tool workflow is what I've followed with the "S32DS for S32 Platform" and the "S32DS for ARM" IDEs. But none of the examples I've seen for MCUXpresso utilize the peripherals tool. Where might I find examples for KW45 that use the peripherals tool? Thanks, Arush Re: KW45 - LPSPI with DMA Hello Arush, Could you help us confirm if you are using an SDK examples as base? Does an SDK example in the latest version[25.06], can match your requirements for SPI DMA transmissions for example [kw45b41evk_lpspi_edma_b2b_transfer_master] ? By any chance do you count with 2 KW4B4I-EVK boards? Best Regards Luis
查看全文
Settings to operate ov2740 camera on i.MX93 FRDM Hi, I am trying to operate an OV2740 camera module on the IMX93 FRDM board.  And when I am trying to capture a frame, the v4l2-ctl hangs : root@imx93frdm:~# v4l2-ctl -d /dev/video0 --set-fmt-video=width=1932,height=1092,pixelformat=BA10 --stream-mmap=4 --stream-count=1 --stream-to=test_capture.raw --verbose VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok VIDIOC_S_FMT: ok Format Video Capture Multiplanar: Width/Height : 1932/1092 Pixel Format : 'BA10' (10-bit Bayer GRGR/BGBG) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3864 Size Image : 4219488 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) The media graph looks to be ok : root@imx93frdm:~# media-ctl -p Media controller API version 6.6.36 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info platform:42800000.bus:camera hw revision 0x0 driver version 6.6.36 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: Sink <- "mxc_isi.0":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "ov2740 2-0036":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: ov2740 2-0036 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev1 pad0: Source [stream:0 fmt:SGRBG10_1X10/1932x1092 field:none crop.bounds:(0,0)/1932x1092 crop:(0,0)/1932x1092] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] My DTS : &clk { assigned-clocks = <&clk IMX93_CLK_CCM_CKO3>; assigned-clock-parents = <&clk IMX93_CLK_24M>; assigned-clock-rates = <24000000>; }; ov2740_mipi: ov2740_mipi@36{ compatible = "ovti,ov2740"; reg = <0x36>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_cam_mclk>; clocks = <&clk IMX93_CLK_CCM_CKO3>; assigned-clocks = <&clk IMX93_CLK_CCM_CKO3>; assigned-clock-rates = <24000000>;  clock-names = "xclk"; clock-frequency = <24000000>; reset-gpios = <&pcal6524 22 GPIO_ACTIVE_LOW>; csi_id = <0>; mipi_csi; rotation = <0>; orientation = <2>;   status = "okay";   port { ov2740_mipi_ep: endpoint { remote-endpoint = <&mipi_csi_in_ep>; bus-type = <4>; data-lanes = <1 2>; clock-noncontinuous; link-frequencies = /bits/ 64 <360000000>; }; }; &cameradev { status = "okay"; };   &isi_0 { status = "okay";   cap_device { status = "okay"; }; };     &mipi_csi { status = "okay"; fsl,rx-lanes = <2>; csis-hs-settle = <16>;   /* Port 0: sink from the sensor */ port@0 { reg = <0>; mipi_csi_in_ep: endpoint { remote-endpoint = <&ov2740_mipi_ep>; data-lanes = <2>; cfg-clk-range = <28>; hs-clk-range = <0x16>; bus-type = <4>; clock-noncontinuous;  }; }; }; The driver is the ov2740 driver from the linux-imx scargapth. I modified it to match the DT and I changed the PLL configuration to match a 24MHz clock : Here is the camera data-sheet : www.elinfor.com/pdf/OmniVision/OV2740-OmniVision.pdf Note that my module regulators are connected to the 3.3 volt, because of this, I didn't define regulators in the DTS  Any advice  BR Basel  Re: Settings to operate ov2740 camera on i.MX93 FRDM Hi @BaselHn! You can request customized drivers through the following link: https://www.nxp.com/support/support/nxp-engineering-services/professional-support-for-processors-and-microcontrollers:PREMIUM-SUPPORT Best regards, Chavira Re: Settings to operate ov2740 camera on i.MX93 FRDM Hi @Chavira  What are the options for support in this case?  BR Basel Re: Settings to operate ov2740 camera on i.MX93 FRDM Hi @BaselHn! Unfortunately, the OV2740 camera module is not officially supported on the i.MX93 platform. The current Linux BSP, device tree configurations, and drivers are not set up to work with this sensor, which may explain the issues you're encountering with v4l2-ctl hanging during frame capture 1. For optimal compatibility and performance, we recommend using one of the validated camera modules for the i.MX93-FRDM board. These modules are tested and supported within the BSP, ensuring smoother integration and functionality. If you still wish to proceed with the OV2740, it would require custom driver development and device tree modifications, which fall outside the scope of standard support. Best regards, Chavira Re: Settings to operate ov2740 camera on i.MX93 FRDM Hi @Chavira  Which drivers are not configured to work with it ?  What we need to patch to make them work  with this camera module ?  BR  Basel  Re: Settings to operate ov2740 camera on i.MX93 FRDM Hi @BaselHn , Unfortunately, that camera is not supported on the iMX93 platform. The current Linux BSP, device tree, and drivers are not configured to work with it. Best regards, Chavira Re: Settings to operate ov2740 camera on i.MX93 FRDM Hi @Chavira  What do you mean it is not supported and why?  Is this means it was not tested on the board? The RPI cam is with ISP what is not need in our application. BR Basel Re: Settings to operate ov2740 camera on i.MX93 FRDM HI @BaselHn! Thank you for contacting NXP Support! Unfortunately, the camera you're referring to is not currently supported on i.MX93 processors. We recommend using one of the validated camera modules for the i.MX93-FRDM board instead. A good option is the RPI-CAM-MIPI, which has been tested and confirmed to work reliably with this platform. Best regards, Chavira
查看全文
Request for S32 Design Studio License Dear Support Team, I am writing to request assistance regarding an issue with my software license activation. When attempting to return my license, I receive the following error message:   CLLReason [errorNo=27, errorString=Error sending a return request to a remote activation server and processing the response. The maximum number of returns is reached, contact your product vendor if you need help. (FNP error 0), flxActMajorErrorNo=0, flxActMinorErrorNo=0, flxActSysErrorNo=0, flxCommErrorNo=0] It appears that I have reached the maximum number of allowed license returns, and I am now unable to deactivate or transfer my license through the usual process. For your reference: Product name/version: S32DS 3.4 License/activation code: F368-1F06-038B-D046 Description of circumstances (e.g., PC formatting, OS changes, etc.): Windows11 I kindly request your support to reset or increase the license return count for my activation code, or otherwise advise on how I can proceed to use my software. Please let me know if you require any additional information. Thank you for your prompt assistance. Best regards, Re: Request for S32 Design Studio License Hello, Thanks for your report. Could you please try to re-activate the license using your existing activation code and S32Design Studio v3.4 (either online or offline activation) Please let us know if you still facing the issue. hope it helps, Stan
查看全文
LVDS Panel Integration on i.MX93 Custom Board (No Display Output) Hello, I am working on integrating an LVDS panel with an i.MX93 custom board using Yocto, but I am facing an issue: the screen remains black. Here is what I have observed so far: The backlight turns on and brightness can be adjusted. The LVDS connector is detected.   The bridge chain appears to be found: CRTC and framebuffer are active Writing random data to /dev/fb0 is successful, but nothing appears on the screen.   Here is the clock summary I am using (please let me know if this seems correct):   Here are some additional kernel logs. But it was said that the messages about failed device links are said to be a noisy logs, but I would like to confirm whether they could be related to my problem. Here is the device tree snippets: backlight: backlight {         compatible = "pwm-backlight";         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_backlight_en>;         power-supply = <&reg_vdd_5v>;         pwms = <&tpm3 3 5000000 0>;         brightness-levels = <0 100>;         num-interpolated-steps = <100>;         default-brightness-level = <50>;         enable-gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;         status = "okay";     };     panel {         compatible = "tianma,aw0800";         power-supply = <&reg_vdd_3v3>;         backlight = <&backlight>;         enable-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;         pinctrl-0 = <&pinctrl_lcd_en>;         data-mapping = "spwg";         status = "okay";         port {             panel_in_lvds0: endpoint {                 remote-endpoint = <&lvds_out>;             };         };     }; }; &dphy {     status = "disabled"; }; &dsi {     status = "disabled"; }; &lcdif {     assigned-clock-rates = <519750000>, /*74250000 x 7*/                           <74250000>,                           <400000000>,                             <133333333>;     status = "okay"; }; &ldb {     status = "okay";     lvds-channel@0 {         #address-cells = <1>;         #size-cells = <0>;         status = "okay";         port@1 {             reg = <1>;             lvds_out: endpoint {                 remote-endpoint = <&panel_in_lvds0>;             };         };     }; }; &ldb_phy {     status = "okay"; }; &tpm3 {     pinctrl-names = "default";     pinctrl-0 = <&pinctrl_pwm1>;     status = "okay"; }; &iomuxc {     pinctrl_pwm1: pwm1grp {         fsl,pins = <             MX93_PAD_GPIO_IO24__TPM3_CH3        0x19e /* BL_PWM*/         >;     };     pinctrl_backlight_en: backlightgrp {         fsl,pins = <             MX93_PAD_GPIO_IO11__GPIO2_IO11   0x51e  /* BL_EN*/         >;     };     pinctrl_lcd_en: panelgrp {         fsl,pins = <             MX93_PAD_GPIO_IO08__GPIO2_IO08   0x51e  /* LCD_EN */         >;     }; };   And the definition of the display:  And the drm display mode is like this: " static const struct drm_display_mode tianma_aw0800_mode = {     .clock = 74250,     .hdisplay = 1280,     .hsync_start = 1280 + 110,     .hsync_end = 1280 + 110 + 40,     .htotal = 1280 + 110 + 40 + 220,     .vdisplay = 720,     .vsync_start = 720 + 5,     .vsync_end = 720 + 5 + 5,     .vtotal = 720 + 5 + 5 + 20, }; static const struct panel_desc tianma_aw0800 = {         .modes = &tianma_aw0800_mode,     .num_modes = 1,     .bpc = 8,     .size = {         .width = 177,         .height = 99,     },     .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,     .bus_flags = DRM_BUS_FLAG_DE_HIGH,     .connector_type = DRM_MODE_CONNECTOR_LVDS, };  Could you please advise on what might be missing or misconfigured.  Your help would be greatly appreciated. Thanks in advance. Re: LVDS Panel Integration on i.MX93 Custom Board (No Display Output) Hello, Thanks for your answer.  I modified like this:  &ldb {     status = "okay";     lvds-channel@0 {         #address-cells = <1>;         #size-cells = <0>;         reg = <0>;         phys = <&ldb_phy1>;         phy-names = "ldb_phy";         status = "okay";         port@1 {             reg = <1>;             lvds_out: endpoint {                 remote-endpoint = <&panel_in_lvds0>;             };         };     }; };   but unfortunately I get the same result, nothing appears on the screen.   We are using the i.MX9332. According to the datasheet, it includes one LVDS interface, and that’s the one we’re using. For the BSP, we’re currently using  scarthgap-6.6.36-2.1.0. Re: LVDS Panel Integration on i.MX93 Custom Board (No Display Output) Hello, Apparently you miss the  phys = <&ldb_phy1>; which LVDS are you trying to interface? Which BSP? the latest BSP include several LVDS dtb on it. Regards
查看全文
将 imx93 的 MIPI_CSI& LVDS 线路配置为 GPIO 引脚 您好, 我们能否将 imx93 的 MIPI_CSI& LVDS 线路配置为 GPIO 引脚? Re: configure MIPI_CSI & LVDS lines of imx93 as GPIO pins 您可以参考 imx93 数据表,mipi csi 和 lvds 焊盘没有复用功能,因此不能用作 gpio 引脚。
查看全文