Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
SDカードをbz2にする方法についてのお問い合わせ IMX8MPを使用してimx-image-core環境で開発しています。(6.1-mickledore imx8mp-lpddr4-evk) device.sdcardは、kernel、rootfs、my_diskなどを組み合わせて作成しました。 uuuで書くと、うまく機能します。 sdcard ファイルは bz2 で圧縮されました。 sdcard ファイルを bz2 にする方法は、以下の通りです。 tar cvfj device.sdcard.bz2 device.sdcard bz2 ファイルを uuu で書き込んだところ、書き込み操作は完了しましたが、カーネルの起動に失敗しました。 「uuu.exe-b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evkdevice.sdcard.bz2" デバイス 0: 不明なデバイス MMC:カードはありません パーティション#0に切り替えて、OK mmc2(パート0)は現行デバイスです ** パーティションテーブルなし - mmc 2 ** パーティションmmc 2:1が見つかりませんでした どこでうまくいかなかったのでしょうか? Re: SDカードをbz2にする方法についてのお問い合わせ 問題にも書きましたが、自分で画像を組み立てました。 bz2 の代わりに zstd を使用しましたが、うまく機能しました。 私が持っているUUUのドキュメント(nxpfrankliによる)にはbz2を使用するように書かれているので、そうしました。 bz2 は圧縮ファイルを正しく書き出しません。 zstd は正常に動作します。 ありがとうございます。 Re: SDカードをbz2にする方法についてのお問い合わせ 私はNXPリファレンスボードを持っており、それに基づいてボードを設計しました。 作成された iamge が mmc にダウンロードされます。 核心的な問題は、非圧縮画像は機能しますが、作成した圧縮画像は機能しないということです。 Re: SDカードをbz2にする方法についてのお問い合わせ NXPリファレンスボードを使用していますか、それとも自分で設計したボードを使用していますか?適切なブートデバイスを選択しましたか、私はあなたがemmcにイメージをダウンロードするつもりであることがわかります。
記事全体を表示
88W8987 GPIO制御 こんにちは。 私は88W8987 + i.MX RTで作業しています。私はいくつかのGPIOを制御する必要がありますが、Wi-FiやBluetoothのドキュメントでも、それを行うために必要なコマンドを見つけることができませんでした。これはどのように行うことができますか? この質問をするのは、製造段階でBluetooth、特にPCMピンをテストする必要があるためです。私がすでに作業したBluetoothコントローラーの中には、PCMにループバック機能があり、これに便利なものがありますが、88W8987にはこの機能がないと思います。 ご清聴ありがとうございました。 よろしくお願いいたします J.V.メロ。
記事全体を表示
Inquiry on how to make sdcard into bz2 I am developing in the imx-image-core environment using IMX8MP. (6.1-mickledore imx8mp-lpddr4-evk) I created device.sdcard by combining kernel, rootfs, my_disk, etc. When written with uuu, it works well. The sdcard file was compressed with bz2. The method for making an sdcard file into bz2 is as follows. tar cvfj device.sdcard.bz2 device.sdcard When I wrote the bz2 file with uuu, the write operation was completed, but kernel booting failed. "uuu.exe -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk device.sdcard.bz2" Device 0: unknown device MMC: no card present switch to partitions #0, OK mmc2(part 0) is current device ** No partition table - mmc 2 ** Couldn't find partition mmc 2:1 Where did it go wrong? Re: Inquiry on how to make sdcard into bz2 As I wrote in the question, I assembled the image myself. I used zstd instead of bz2, and it worked well. The UUU documentation I have (by nxpfrankli) says to use bz2, so I did that. bz2 does not write compressed files correctly. zstd works fine. thank you. Re: Inquiry on how to make sdcard into bz2 For detailed usage of UUU, see github.com/NXPmicro/mfgtools/wiki. Re: Inquiry on how to make sdcard into bz2 Hi @kiyoung  For the uncompressed image works well, do you build them yourself or the demo images? Re: Inquiry on how to make sdcard into bz2 I have an NXP reference board and designed the board based on it. The created iamge is downloaded to mmc. The core question is that the uncompressed image works, but the compressed image I created does not work. Re: Inquiry on how to make sdcard into bz2 Are you using NXP reference board or the board you designed yourself? Have you choose the proper boot device, I see that you are going to downlaod images to emmc.
記事全体を表示
MC33SB0400ESR2和FS32K142HFT0VLHT的晶圆是多少nm的? MC33SB0400ESR2和FS32K142HFT0VLHT的晶圆是多少nm的? 回复:MC33SB0400ESR2和FS32K142HFT0VLHT的晶圆是多少nm? 你好@nihaoROBOT S32K1的工艺为90nm,MC33SB0400ESR2的工艺为250nm。
記事全体を表示
SPDIF 最大サンプリング レート i.MX RT1060のSPDIFを使う予定です。 SPDIFが入力および出力できる最大サンプルレートはどれくらいですか? 192kHzは正しいですか? 日時:SPDIF最大サンプリングレート 正しい、最大192kHz。 よろしくお願いいたします オマル
記事全体を表示
88W8987 GPIOs Control Hi guys. I am working with 88W8987 + i.MX RT. I need to control some GPIOs, but I was unable to find the necessary commands to do that, neither in Wi-Fi or bluetooth documentation. How can this be done? I asking this question because I need to test the bluetooth in the production phase, specially the PCM pins. Some bluetooth controllers that I have already worked have a loopback feature in PCM that is useful for this, but I think that the 88W8987 doesn't have this feature. Thanks for your attention. Best Regards, J. V. Melo. Re: 88W8987 GPIOs Control Hi Daniel, Thanks for your reply. Regards, J. V. Melo. Re: 88W8987 GPIOs Control Hi, Sorry for the late reply. The GPIO's are configurable, but the configuration is saved in firmware, and this can't be changed by customers. For BT testing, we usually recommend the SDK demo edgefast_bluetooth_shell. You can find more information in UM11442. I'm sorry for the inconvenience. Regards, Daniel. Re: 88W8987 GPIOs Control Hi Daniel, The HFP has already been running with a proprietary stack. The point is, I am trying to execute a simple test in the production phase and to do that I would like to use the PCM pins like GPIOs, taking then control. As far has I know the datasheed says that these pins can be used like GPIOs, instead of the default PCM function. How can this be done? I mean, pin setup, pin read and pin control. Thanks. Re: 88W8987 GPIOs Control Do you want to test HFP? RT1170 EVK requires a HW rework to enable PCM (I understand you are using a custom board). Just in case you based your design on the EVK, there are some guidelines to enable PCM in Hardware Rework Guide for EdgeFast Bluetooth Protocol Abstraction Layer. This document is available in the following directory of the SDK bundle SDK_2_16_100_MIMXRT1170-EVKB\docs\wireless\bluetooth\edgefast_bluetooth. Regards, Daniel. Re: 88W8987 GPIOs Control Hi Daniel. First, thanks for you quick reply. What RT are you using? i.MX RT1176. Are you using an EVK? No, I have a custom board. What SDK are you using? 2.13.1 SDK. Regarding Wi-Fi, I am working with the SDK drivers. Regarding Bluetooth, I am working with a proprietary stack. Are you using a module for 88W8987? Yes. It is LBEE5QD1ZM from Murata. Thanks. Re: 88W8987 GPIOs Control Hi, What RT are you using? Are you using an EVK? What SDK are you using? Are you using a module for 88W8987? Regards, Daniel.
記事全体を表示
How many nm is the wafer of MC33SB0400ESR2 and FS32K142HFT0VLHT? How many nm is the wafer of MC33SB0400ESR2 and FS32K142HFT0VLHT? Re: How many nm is the wafer of MC33SB0400ESR2 and FS32K142HFT0VLHT? Hi@nihaoROBOT The process of S32K1 is 90nm,and the MC33SB0400ESR2 is 250nm.
記事全体を表示
88W8987 GPIO控制 嗨,大家好。 我正在使用 88W8987 + i.MX RT。我需要控制一些 GPIO,但在 Wi-Fi 或蓝牙文档中都找不到执行此操作所需的命令。这该如何做呢? 我问这个问题是因为我需要在生产阶段测试蓝牙,特别是 PCM 引脚。我已经使用过的一些蓝牙控制器在 PCM 中具有环回功能,这很有用,但我认为 88W8987 没有此功能。 感谢您的关注。 此致, JV Melo。
記事全体を表示
S32K3 GPIO HIGH-Z Hi,NXP experts In S32DS3.5, how do I configure pin to state HIGH-Z?   S32K312+RTD4.0.0 In picture 1 it says can be configured as HIGH-Z,but I can't find the configuration item. It is configurable in EB(picture 3). Re: S32K3 GPIO HIGH-Z For anyone looking on using Siul2_Port_Ip_SetPinDirection to set to Hi-Z, here is how to call the function: Siul2_Port_Ip_SetPinDirection(PORT, PIN, SIUL2_PORT_HI_Z); For input variable 1 of the function, which is `Siul2_Port_Ip_PortType * const base`, you need to use the defines mentioned in `Siul2_Port_Ip_Defines.h` and not the ones `Siul2_Port_Ip_Cfg.h`. You can find out what define the Pin you are using belongs to by checking in  `Siul2_Port_Ip_Cfg.h` as shown below: Now that PTD_H_HALF is known, which is Port D High Half Base, find it in `Siul2_Port_Ip_Defines.h` and use it as the first input argument.  For input variable 2, you can use the defines mentioned in  `Siul2_Port_Ip_Cfg.h` which is nothing but the Pin Number.  Once the pin is set to SIUL2_PORT_HI_Z, you do not have to use Siul2_Dio_Ip_WritePin function as it is only used to set the Pin to High or Low and not for SIUL2_PORT_HI_Z.    I hope this gives a bit more clarity.  Re: S32K3 GPIO HIGH-Z Hi @Chenxu1  Unlike EB Tresos, S32 ConfigTools does not have the option to set the PortPin Direction to PORT_PIN_HIGH_Z, as this is the default value. If you want to change it, you can use the functions Siul2_Port_Ip_SetPinDirection() or Port_SetPinDirection(). BR, VaneB
記事全体を表示
integrating KSZ8795 on imx8mplus This is how I changed the device tree: &eqos { //no-change-(for a qualcomm based eth chip) pinctrl-names = "default"; //eth1 pinctrl-0 = <&pinctrl_eqos>; phy-mode = "rgmii-id"; phy-handle = <&ethphy0>; status = "okay"; mdio { compatible = "snps,dwmac-mdio"; #address-cells = <1>; #size-cells = <0>; ethphy0: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0>; reset-assert-us = <10000>; reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>; reset-deassert-us = <30000>; eee-broken-1000t; at803x,vddio-1p8v; at803x,vddio-disable; }; }; }; &fec { //linked to ksz8795 pinctrl-names = "default"; //eth0 pinctrl-0 = <&pinctrl_fec>; phy-mode = "rgmii-id"; fsl,magic-packet; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; ----------------------------------------------------------------------------------------- &ecspi2 { #address-cells = <1>; #size-cells = <0>; fsl,spi-num-chipselects = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>, /*SS0*/ <&gpio4 4 GPIO_ACTIVE_LOW>, /*SS1*/ <&gpio4 5 GPIO_ACTIVE_LOW>; /*SS2*/ clocks = <&clk IMX8MP_CLK_ECSPI2_ROOT>, <&clk IMX8MP_CLK_ECSPI2_ROOT>; clock-names = "ipg", "per"; status = "okay"; ksz8795: switch@0 { reg = <0>; compatible = "microchip,ksz8795"; spi-max-frequency = <5000000>; pinctrl-names = "default"; /* spi-cpha; spi-cpol; */ status = "okay"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; label = "lan1"; phy-mode = "rgmii-id"; fixed-link { speed = <100>; full-duplex; }; }; port@1 { reg = <1>; label = "lan2"; phy-mode = "rgmii-id"; fixed-link { speed = <100>; full-duplex; }; }; port@2 { reg = <2>; label = "lan3"; phy-mode = "rgmii-id"; fixed-link { speed = <100>; full-duplex; }; }; port@4 { reg = <3>; label = "cpu"; phy-mode = "rgmii-id"; ethernet = <&fec>; fixed-link { speed = <1000>; full-duplex; }; }; }; }; spidev1: spi@1 { reg = <1>; compatible = "rohm,dh2228fv"; spi-max-frequency = <500000>; }; spidev2: spi@2 { reg = <2>; compatible = "rohm,dh2228fv"; spi-max-frequency = <500000>; }; }; ---------------------------------------------------------------------------- The board is booted and i loads the module: ksz_common, ksz8795 and ksz8795_spi I can see the respective nodes formed. # ifconfig eth0: flags=4163 mtu 1501 inet6 fe80::8bd8:a721:8c85:3a61 prefixlen 64 scopeid 0x20 ether 38:d5:47:00:2e:9d txqueuelen 1000 (Ethernet) RX packets 42 bytes 3094 (3.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 73 bytes 12753 (12.7 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4099 mtu 1500 ether 38:d5:47:00:2e:9e txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 52 lan1: flags=4163 mtu 1500 inet6 fe80::f4f3:314b:f7c3:9bd5 prefixlen 64 scopeid 0x20 ether 38:d5:47:00:2e:9d txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2434 (2.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lan2: flags=4163 mtu 1500 inet6 fe80::1bd1:9463:93c0:732c prefixlen 64 scopeid 0x20 ether 38:d5:47:00:2e:9d txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2434 (2.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lan3: flags=4163 mtu 1500 inet6 fe80::833e:9b97:6b1e:82ae prefixlen 64 scopeid 0x20 ether 38:d5:47:00:2e:9d txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2434 (2.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ----------------------------------------------------------------------------------------------------------------------------- I can also see an error from the spi-driver from dmesg log: DBUG: KSZ_common:ksz_switch_register: of_get_phy_mode returned -22 [ 57.561350] DBUG: KSZ_common:ksz_switch_register: Retrieved PHY mode 0 [ 57.561353] DBUG: KSZ_common:ksz_switch_register: Failed to retrieve PHY mode, error -22 from ksz_common.c: if (dev->dev->of_node) { printk("DBUG: KSZ_common:ksz_switch_register: Device tree node found, retrieving PHY mode\n"); ret = of_get_phy_mode(dev->dev->of_node, &interface); if (ret == 0) { dev->compat_interface = interface; printk("DBUG: KSZ_common:ksz_switch_register: Retrieved PHY mode %d\n", interface); } else { printk("DBUG: KSZ_common:ksz_switch_register: Failed to retrieve PHY mode, error %d\n", ret); } PRINT was added by me to debug-this is the only "error msg" i see from driver. But the driver loads successsfully Regarding phy-mode: There are other prints after above error : [ 57.576542] CLSU:KSZ8795: Configuring addr 0x87, bits 0x8, set 1 [ 57.576597] CLSU:KSZ8795: Configuring port 4, offset 0x0, bits 0x40, set 0 [ 57.576631] CLSU:KSZ8795: Configuring port 4, offset 0x2, bits 0x80, set 0 [ 57.576665] CLSU:KSZ8795: Configuring port 4, offset 0x0, bits 0x20, set 1 [ 57.576717] CLSU:KSZ8795: Configuring CPU port [ 57.576750] CLSU:KSZ8795: Setting RGMII mode So i suppose the phy-mode is being set to rgmii ---------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------- ISSUE : I connected an ethernet cable between my pc and the board to check the comm ,Set a static ip for eth0 on board. i can see a link is established b/w them . But i cannot ping each other. Data packets are not seem to be receiving at both ends.(Validated that hardware is working fine) from device to pc # ping 192.168.1.50 PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data. From 192.168.1.30 icmp_seq=1 Destination Host Unreachable Since link is being establish and ping is not happening i suspect - it must be some configuration issue. Either in the device tree or in the Register Writes. Please help me to troubleshoot the issue. Re: integrating KSZ8795 on imx8mplus It worked. The issue was that the driver I used was not updated. It was a 5 port switch. And the fifth port was not registering as it does (N-1) check on the ports. with tot no. of ports set to N=5. Adjusting the value slightly solved the issue. Re: integrating KSZ8795 on imx8mplus Hi You can refer other dts to set switch node. switch: switch@5f { compatible = "microchip,ksz9897"; reg = <0x5f>; pinctrl-0 = <&pinctrl_ksz>; interrupt-parent = <&gpio4>; interrupts = <18 IRQ_TYPE_EDGE_FALLING>; phy-mode = "rgmii-id"; ports { #address-cells = <1>; #size-cells = <0>; lan1: port@0 { reg = <0>; label = "lan1"; phy-mode = "internal"; local-mac-address = [00 00 00 00 00 00]; }; lan2: port@1 { reg = <1>; label = "lan2"; phy-mode = "internal"; local-mac-address = [00 00 00 00 00 00]; }; lan3: port@2 { reg = <2>; label = "lan3"; phy-mode = "internal"; local-mac-address = [00 00 00 00 00 00]; }; lan4: port@3 { reg = <3>; label = "lan4"; phy-mode = "internal"; local-mac-address = [00 00 00 00 00 00]; }; port@5 { reg = <5>; label = "cpu"; ethernet = <&fec1>; phy-mode = "rgmii-id"; fixed-link { speed = <1000>; full-duplex; }; }; Best Regards Zhiming Re: integrating KSZ8795 on imx8mplus kernel is 5.10
記事全体を表示
新しい MBDT バージョン (1.5.0) のピン配置 S32K3ファミリ用MBDTの新バージョン(1.5.0)へ開発を移行しています。 LCU出力など、さまざまな機能用にいくつかのピンを構成する必要がありますが、新しいバージョンのS32configツール(1.7)は以前のもののように機能しないことがわかりました。 MCAL グループの下に新しい PORT グループが作成され、DRIVERS の下の古い SIUL2-PORT は削除されました。以前のバージョンでは、PIN VIEW に新しいピンが追加されるたびに。PORT グループの設定が更新されません。 この新しいバージョンでピン構成を追加または変更する適切な手順は何ですか。 よろしくお願いいたします。 Re: 新しい MBDT バージョン (1.5.0) のピン構成 情報をありがとう。これで、ピンを正しい方法で構成できます さらに、PWM期間が更新されないという問題があります。すべてのPWM出力は、ConfigToolで設定されたデフォルトのDTにフリーズします。 EMIOS0 チャネル 1 と 2 をアンシングしています。 このテーマについて何か考えはありますか。
記事全体を表示
LLCE_CAN interface did not show up with bsp38 Hi, I modified the conf/local.conf file and added llce_can in DISTRO_FEATURES:append. I have all four .bin files in the pre-defined firmware folder, and the LLCE firmware version is 1.0.8. The SD card image used is fsl-image-auto. When the board boots up, I can see that the LLCE kernel modules are loaded. However, running ifconfig -a doesn't show any llce_can interfaces. I've dumped the device tree from the running system, and all llce_can interfaces have their status set to OK. Can anyone help me identify what might be wrong? I've included more details below. root@s32g399ardb3:~# lsmod Module Size Used by pfeng 565248 0 llce_can 24576 0 llce_mailbox 32768 1 llce_core 16384 0 grep the dmesg, only a few lines are llce related root@s32g399ardb3:~# dmesg | grep -i llc [ 6.777298] Modules linked in: llce_mailbox(+) llce_core [ 6.807139] lr : llce_mb_last_tx_done+0xb8/0x170 [llce_mailbox] [ 6.894104] execute_hif_cmd+0x70/0xe0 [llce_mailbox] [ 6.899138] get_fw_version+0x84/0xb0 [llce_mailbox] [ 6.904087] llce_mb_probe+0x4c8/0x854 [llce_mailbox] [ 6.969889] llce_mb_driver_init+0x24/0x1000 [llce_mailbox] root@s32g399ardb3:~# these are related to some kernel exception Starting Load Kernel Modules... Starti[ 6.756042] systemd[1]: Starting Generate network units from Kernel command line... ng Generate network �…ts from Kernel command li[ 6.769759] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP n[ 6.777298] Modules linked in: llce_mailbox(+) llce_core e[ 6.782664] CPU: 7 PID: 156 Comm: systemd-modules Not tainted 5.15.119-rt65+ge18f05316cd9 #1 6.791169] Hardware name: NXP S32G399A-RDB3 (DT) [[ 6.795944] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) 0[ 6.802973] pc : __memcpy_fromio+0x48/0xa0 m[ 6.807139] lr : llce_mb_last_tx_done+0xb8/0x170 [llce_mailbox] .[ 6.813130] sp : ffffffc00a0bb600 .[ 6.816514] x29: ffffffc00a0bb600 x28: ffffff885f8fdc50 x27: 0000000000000000 .[ 6.823718] x26: ffffffc00a0bb6b0 x25: ffffffc00ba80000 x24: ffffff88009621c8 [ 6.830923] x23: 0000000000000000 x22: 0000000000000000 x21: ffffff88017b4000 [ 6.838127] x20: ffffff8801638080 x19: 0000000000000001 x18: 0000000000000001 [ 6.845239] x17: 0000000000000000 x16: ffffff8800962128 x15: 0000000000000000 [ 6.852354] x14: ffffffffffffffff x13: 0000000000000020 x12: 0101010101010101 [ 6.859471] x11: 0000000000000040 x10: ffffff88009ae128 x9 : 0000000000000000 [ 6.866588] x8 : ffffffc00a0bb848 x7 : 0000000000000000 x6 : 0000000000000198 [ 6.873706] x5 : 0000000000000000 x4 : ffffffc00bab9f70 x3 : ffffffc00a0bb848 [ 6.880823] x2 : 0000000000000198 x1 : ffffffc00bab9de0 x0 : ffffffc00a0bb840 [ 6.887942] Call trace:  Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi Daniel, Thank you for your support. I'm okay with the current state now and will create a new topic if I encounter any new issues. Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi, Thanks for your feedback. Aside from what we have mentioned before, we don't have additional suggestions. We do apologize. Please, let us know. Re: LLCE_CAN interface did not show up with bsp38 Hi Daniel, Thank you for your support. I followed your advice and removed all LLCE .bin files. I also used both -c cleansstate and -c cleanall to clean up the build environment, and then ran bitbake -f fsl-image-auto to regenerate the entire image. However, the LLCE interfaces are still active and running. I’m considering deleting the entire tmp folder and performing a complete rebuild. If you have any other suggestions, please let me know. Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi, Thanks for your feedback. Aside from the clean, we can recommend also removing the LLCE-FW binaries from the folder, to understand if this prevents the automatic loading of the components. Please, let us know. Re: LLCE_CAN interface did not show up with bsp38 Hi Daniel, I used bitbake -c cleanall fsl-image-auto before rebuilding the image. Is this sufficient to clean up everything from the previous build? Do you have any other suggestions? Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi, Thanks for your feedback. Below will be some comments on regards of your questions: How does the kernel load the llce-can kernel modules automatically? [DA]: For the following statement: "I also enabled NXP LLCE CAN support in the kernel configuration... ... After rebuilding fsl-image-auto..." Did you clean your build? Could be that remnants of the previous build were still available, hence it still took the LLCE-FW available. How does the OS obtain the LLCE firmware .bin files without explicit specification? [DA]: If the LLCE module was enabled, and the binaries were taken by the build as mentioned under the previous question, then the OS used the binaries available to activate LLCE. Please, let us know. Re: LLCE_CAN interface did not show up with bsp38 Hi Daniel, Sorry for the confusion. Current Setup: I have the 1.0.7 LLCE firmware(.bin files) on my local build machine, which the NXP_FIRMWARE_LOCAL_DIR in the local.conf file points to. However, 'llce-can' is not included in DISTRO_FEATURES:append. I also enabled NXP LLCE CAN support in the kernel configuration using menuconfig, setting it to 'M' (module), as I couldn't make it a built-in module. After rebuilding fsl-image-auto and booting the system, I found that the llce-can kernel module loads automatically, and all llce-can interfaces are up and running. I did not manually copy the llce-can kernel module .ko files or the LLCE CAN .bin files to the board. Concerns: I did not specify 'llce-can' in the local.conf file. I did not manually copy any .ko files to the board. I did not specify how the OS retrieves the LLCE firmware .bin files. Questions: How does the kernel load the llce-can kernel modules automatically? How does the OS obtain the LLCE firmware .bin files without explicit specification? I need to understand this behavior to ensure the interfaces don't disappear unexpectedly in the future. Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi, Thanks for your feedback. We understand that your image was built with LLCE-FW v1.0.8 and not rebuilt with LLCE-FW v1.0.7, is this correct? As for the behavior, seems to be that the binaries were missing inside the Linux image, hence LLCE was not being initialized. Once the binaries were available, then it could start. Please, let us know. Re: LLCE_CAN interface did not show up with bsp38 Hi Daniel, I did not rebuild the LLCE 1.0.7 firmware; it was prebuilt and downloaded, then copied to the /lib/firmware folder on the SD card. Based on your suggestion, I tried using manual steps. Interestingly, after I removed llce_can from the DISTRO_FEATURES:append in the local.conf file (and previously set the LLCE CAN as a module in the kernel configuration), I rebuilt the image. Upon booting the system, all LLCE CAN and logger interfaces were present. I checked the /lib/firmware folder and found only the PFE firmware; no LLCE firmware binary files were present. I even tried using -c cleanall to rebuild the image, but the result was the same—every interface was up and running. I am confused about how the LLCE CAN interface is operational without copying the kernel module and firmware files. Here is the change I made in the local.conf file. Additionally, the LLCE firmware binary files are still physically present in the NXP_FIRMWARE_LOCAL_DIR. DISTRO_FEATURES:append = " ipc-shm pfe " NXP_FIRMWARE_LOCAL_DIR = "/home/xhu/workspace/fsl-auto-yocto-bsp/nxp_firmware_files" Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi, Thanks for your feedback. Did you re-build your image with LLCE-FW v1.0.7? Or you only replaced the binaries? If you build your image for v1.0.8, we understand that it might have an undefined behavior if you just replaced the LLCE-FW binaries.  Also, we could recommend doing the Manual compilation steps for LLCE (provided under the BSP38.0 User Manual) to understand if the problem might be related to yocto itself. Please, let us know. Re: LLCE_CAN interface did not show up with bsp38 Hi Daniel, Thank you for your quick response. I replaced all four .bin files in /lib/firmware on the SD card with the 1.0.7 LLCE firmware. Unfortunately, the llce_can interfaces are still missing. I noticed a failure when loading the llce_core kernel module during bootup. I've posted a screenshot below and included the md5sum of the .bin files for cross-checking. Apr 28 17:42:26 s32g399ardb3 systemd-modules-load[156]: Inserted module 'llce_core' Apr 28 17:42:26 s32g399ardb3 systemd[1]: systemd-modules-load.service: Main process exited, code=killed, status=11/SEGV Apr 28 17:42:26 s32g399ardb3 systemd[1]: systemd-modules-load.service: Failed with result 'signal'. Apr 28 17:42:26 s32g399ardb3 systemd[1]: Failed to start Load Kernel Modules. Notice: journal has been rotated since unit was started, output may be incomplete. root@s32g399ardb3:~# root@s32g399ardb3:~# lsmod Module Size Used by pfeng 565248 0 llce_can 24576 0 llce_mailbox 32768 1 llce_core 16384 0 root@s32g399ardb3:~# md5sum /lib/firmware/*.bin 7031a5834b95e73c77f4da72bab44dcb /lib/firmware/dte.bin 96a3ac83a650418f331b560d5c8c7d1a /lib/firmware/frpe.bin fb2e43b53f9470c9fb4348d15b81409b /lib/firmware/ppe_rx.bin ee4bfaaf2a172e7a842fb272aaa85004 /lib/firmware/ppe_tx.bin Thanks, XD Re: LLCE_CAN interface did not show up with bsp38 Hi, We understand that you are using LLCE-FW v1.0.8 with BSP38.0. If so, we see under the BSP38.0 release notes that the compatible LLCE-FW version is v1.0.7 [Page 2, Linux BSP 38.0 Release Notes for S32G3, 10/2023]: We can recommend using LLCE-FW v1.0.7 to confirm the problem is not related to compatibility. Please, let us know.
記事全体を表示
如何更改对象聚焦时的显示样式 当我使用机械按键时,屏幕上的物体会出现焦点效果,但是目前焦点效果是浅蓝色的边框,不太明显,有什么办法可以改变这个焦点效果的显示吗? 回复:当对象处于焦点时如何更改显示样式 谢谢您的回复。已经解决了。
記事全体を表示
オブジェクトにフォーカスが合っているときに表示スタイルを変更する方法 メカニカルキーを使用すると、画面上のオブジェクトにフォーカス効果がありますが、現在、フォーカス効果は水色の境界線であまり見えませんが、このフォーカス効果の表示を変更する方法はありますか? Re:オブジェクトにフォーカスが合っているときに表示スタイルを変更する方法 返信ありがとうございます。解決しました。
記事全体を表示
How to change the display style when an object is in focus When I use the mechanical keys, the objects on the screen will have a focus effect, but currently the focus effect is a light blue border and not very visible, is there any way to change the display of this focus effect? Re: How to change the display style when an object is in focus Thanks for the reply. It's solved. Re: How to change the display style when an object is in focus Hello @acd , Of course there is a way to change. Find the 'state' option in the 'Attributes' section on the right, change the 'default' state to the 'focused' state, and make changes to the widget's properties to do this.     Best Regard Liu
記事全体を表示
i.MX8ULP access pbridge2 from m33 Hello, Looking at the i.MX 8ULP architecture diagram in the imx8ulp reference manual, we can see that the PBridge2 is part of the DSP domain that is within the Real Time Domain. I understand that the M33 core is not directly connected to the DSP domain, but I see that the crossbars (XBAR_RTD and XBAR_DSP) are connected; would it be possible to access the DSP devices from the M33 core? When I tried to use LPSPI2 in the DPS domain I could only get the M33 core to hang/crash despite setting up the clocks as per examples/evkmimx8ulp/dsp_examples/hello_world_usart; so I assume that if it is accessible at all there must be some operation required to map the pbridge2 region in the cm33 OS. The motivation here is that the imx8ulp has much less IO than the previous SoC we were using, and we'd like to use LPSPI2 and LPUART2 (both connected to pbridge2 in the DSP domain) from the CM33 core Thank you, Dominique Re: i.MX8ULP access pbridge2 from m33 FWIW for anyone else following this, we were able to access LPSPI1 after looking at this example: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Test-LPUART2-DSP-domain-on-i-MX8ULP-M33/ta-p/2084372 (Looking back at my diff I guess I was missing a call to Fusion_Init()? It also took us quite a while to figure out how to suspend properly (deep sleep), doing Fusion_Deinit() and also resetting up trdc after resume, but it all worked out ultimately) Thanks Re: i.MX8ULP access pbridge2 from m33 Thanks~I will try it again! Re: i.MX8ULP access pbridge2 from m33 Yes, GPIOs (PTA~PTC) all are usable from CM33; you just need to set pinmux as GPIO. Re: i.MX8ULP access pbridge2 from m33 well, Thanks! I want to test LPUART2 loopback, so I have tried to test RX and TX as gpio loop.But it can't work.I want to confirm even if LPUART2 is in DSP domain, CM33 can alse control pins, right? Re: i.MX8ULP access pbridge2 from m33 We gave up on this and implemented gpio bitbanging for SPI instead of using LPSPI2. I still believe it could be possible in theory but I just don't see how given the TRDC config does not work. If you find a solution I'd still be interested eventually as bitbanging is slower/less efficient than LPSPI, but this is not a priority right now. Thanks Re: i.MX8ULP access pbridge2 from m33 Hi! Can you drive Pbrigde2 peripherals right now? I add some configutation in void BOARD_SetTrdcGlobalConfig(), but the result is that the reg of LPUART2[PCC_REG(kCLOCK_Lpuart2)] is 0. It means the peripheral is not present... Re: i.MX8ULP access pbridge2 from m33 Hi @daisukemizobuch  We can't control the module resources outside of the dsp core, as I said in the other case. Best Regards Zhiming Re: i.MX8ULP access pbridge2 from m33 hi @Zhiming_Liu ; Thank you. Looking forward for your response. Best Regards mizo Re: i.MX8ULP access pbridge2 from m33 Hi @daisukemizobuch  @martinetd  Let me take some time to test this. Best Regards Zhiming Re: i.MX8ULP access pbridge2 from m33 hi @Zhiming_Liu ; Is there any new information on this? I would be very grateful if you have any new information. Best Regards mizo Re: i.MX8ULP access pbridge2 from m33 hi @Zhiming_Liu ; Thank you for the reply and sorry for the slow response. I am not sure we agree on what I am trying to do here. The dsp_pdm_sai example (examples/evkmimx8ulp/dsp_examples/pdm_sai) certainly controls the PDM, but it does so from dsp/main_dsp.c which runs on the DSP core, and the M33 core does not do anything after starting the DSP core. I am trying to access DSP peripherals directly from the M33 core without starting the DSP core (I do not have a license to use XCC to modify or build DSP images, so using the mailbox to control the DSP core from the M33 is not a solution either). The dsp pdm_sai example also does not modify the TRDC (MRC/MBC) at all from the common board configuration. I've tried adding more blocks to the TRDC Mbc without much success. I tried looking at the trdc example (examples/evkmimx8ulp/driver_examples/trdc) and it does not look like I get a fault when accessing PCC2->PCC_LPSPI2 (0x2810_2034) but LPSPI2 cannot work if that register is 0. I have attached the patch I tried with the trdc example, here is the output I get printing PCC2->PCC_LPSPI2 (and LPSPI1 for sanity checking), after having set the MDC as you suggested (for the PCC2 block) TRDC example start other init XXXXXXX LPSPI1 80000000 @ 280300fc ; LPSPI2 0 @ 28102034 Set the MRC selected memory region not accessiable Violent MRC access at address: 0x40000000 The MRC selected region is accessiable now Set the MBC selected memory block not accessiable Violent MBC access at address: 0x28800000 The MBC selected block is accessiable now TRDC example Success It would be greatly appreciated if you could point me in the right direction. Thank you, Dominique Re: i.MX8ULP access pbridge2 from m33 Hi Please add another mbcidx to map pcc2. The dsp_pdm_sai is a good example to show how to control pdm(dsp domain) from M33. mbcBlockConfig.memoryBlockIdx = 2U;//PCC2 TRDC_MbcSetMemoryBlockConfig(TRDC, &mbcBlockConfig); Best Regards Zhiming Re: i.MX8ULP access pbridge2 from m33 Thank you for the domain name, I had missed it. Unfortunately the m33 core still hangs when I try to send a message over LPSPI2. I've looked a bit closer at where this hangs, and LPSPI_MasterTransferReadDataInFifoNoBuf() hangs as  LPSPI_GetStatusFlags(LPSPI2) never changes from 0. Going earlier, at the start of LPSPI_MasterTransferBlocking() the example I'm using (examples/evkmimx8ulp/driver_examples/lpspi/polling_b2b_transfer/master) already called LPSPI_MasterInit(), so LPSPI2->CR should be 1 (enabled) but it's not; it stays at 0 even immediately after LPSPI_Enable(base, true) so I'm not sure if my problem here is with the TRDC/MBC (if it was the MBC, I'd expect any access to LPSPI2 registers to either hang or reset the controller, which it does not -- or does it just ignore anything written and always return 0 if access isn't set properly?) Going back even further, the PCC2 memory map doesn't seem mapped? The manual says PCC2 base address: 2810_2000h / PCC_LPSPI2 at offset 34h which should contain at least 8000_0000h if present (PR bit), but it is 0. (meanwhile PCC_LPSPI1 at 2803_00FCh contains 9200_0000h at that point) OTOH I don't see anything explicitly mapping PCC0 (2803_0000h) either so I'm not sure what would be required here. What do you think; am I missing something else before (or after) the TRDC settings? Thank you. Re: i.MX8ULP access pbridge2 from m33 Hi There is TRDC_M33_DOMAIN_ID in board.h,  you can use it.  /* non secure state can access LPSPI2(T-MBC3) for M33 */ mbcBlockConfig.memoryAccessControlSelect = TRDC_MBC_ACCESS_CONTROL_POLICY_ALL_INDEX; mbcBlockConfig.nseEnable = true; mbcBlockConfig.mbcIdx = 3U; mbcBlockConfig.domainIdx = TRDC_M33_DOMAIN_ID; mbcBlockConfig.slaveMemoryIdx = 0U; mbcBlockConfig.memoryBlockIdx = 13; TRDC_MbcSetMemoryBlockConfig(TRDC, &mbcBlockConfig); Referring the pdm_sai dsp demo, we need take the memoryBlockIdx from PBRIDGE2 memory map. For LPSPI2, the memoryBlockIdx should be 13 Best Regards Zhiming Re: i.MX8ULP access pbridge2 from m33 sorry for double update, patches actually attached... Re: i.MX8ULP access pbridge2 from m33 Hello @Zhiming_Liu  Thank you for the reply! Checking the reference manual, in my case I want to access pbridge2 devices from the m33 so I found that MBC3 controls 18 4k blocks for Pbridge2; (I'm not quite sure TRDC_GetMbcHardwareConfig(TRDC, &mbcHwConfig, 3, 0) (and higher slaves) all return a mbcHwConfig.blockNum=0 ; so perhaps I am missing some prerequisite? But then again it doesn't take domains so I don't think I'm understanding this properly...) Ignoring the above and basing myself on the manual I've tried to set access to TRDC_MBC_ACCESS_CONTROL_POLICY_ALL_INDEX + nseEnabled to all domains (domain 0-7, slave 0, block 0-2) and while that didn't seem to fail that didn't help either, my m33 program still hangs/crashes as soon as it accesses LPSPI2 (I've also removed any other reference to MBC3 I could find in board.c; and also picked a clock on Pcc2 for pbridge2 to set up as per the dsp example) I've attached diffs that apply on top of https://github.com/NXPmicro/mcux-sdk b565979c2155efc49ffcc8cdaa1f932e19a4d0e5 and https://github.com/nxp-mcuxpresso/mcux-sdk-examples fc18ff0c12ba90fe71714eaa4244717efa18c61c Would you happen to know what's missing? Re: i.MX8ULP access pbridge2 from m33 Hi You need set MBC policy in  BOARD_SetTrdcGlobalConfig referring the pbridge1, using domainIdx to control which domain can access it.   ..... /* for DMA1, USB0, USB1, ENET, UDSHC0, USDHC1, UDSHC2, CAMM Master(default domain id is 1), default TRDC * configuration */ /* non secure state can access Pbridge1(MBC2_MEM1) for DMA1, USB0, USB1, ENET, UDSHC0, USDHC1, UDSHC2, CAMM * Master */ mbcBlockConfig.memoryAccessControlSelect = TRDC_MBC_ACCESS_CONTROL_POLICY_ALL_INDEX; mbcBlockConfig.nseEnable = true; /* non secure state can access the block for DMA1, USB0, USB1, ENET, UDSHC0, USDHC1, UDSHC2, CAMM Master */ mbcBlockConfig.mbcIdx = 2U; /* MBC2 */ mbcBlockConfig.domainIdx = 1U; /* MBC2_DOM1 */ mbcBlockConfig.slaveMemoryIdx = 1U; /* MBC2_DOM1_MEM1 */ TRDC_GetMbcHardwareConfig(TRDC, &mbcHwConfig, mbcBlockConfig.mbcIdx, mbcBlockConfig.slaveMemoryIdx); for (n = 0U; n < mbcHwConfig.blockNum; n++) { mbcBlockConfig.memoryBlockIdx = n; /* MBC2_DOM1_MEM1_BLK_CFG_Wx */ TRDC_MbcSetMemoryBlockConfig(TRDC, &mbcBlockConfig); } .... /* non secure state can access PCC1(PBridge1 slot 17) and ADC1(PBridge1 slot 34) for cortex-A35 */ mbcBlockConfig.memoryAccessControlSelect = TRDC_MBC_ACCESS_CONTROL_POLICY_ALL_INDEX; mbcBlockConfig.nseEnable = true; /* non secure state can access the block for cortex-A35 */ mbcBlockConfig.mbcIdx = 2U; /* MBC2 */ mbcBlockConfig.domainIdx = 7U; /* MBC2_DOM7 */ mbcBlockConfig.slaveMemoryIdx = 1U; /* MBC2_DOM7_MEM1 */ mbcBlockConfig.memoryBlockIdx = 17U; /* MBC2_DOM7_MEM1_BLK_CFG_W17 */ TRDC_MbcSetMemoryBlockConfig(TRDC, &mbcBlockConfig); mbcBlockConfig.memoryBlockIdx = 34U; /* MBC2_DOM7_MEM1_BLK_CFG_W34 */ TRDC_MbcSetMemoryBlockConfig(TRDC, &mbcBlockConfig); .... Best Regards Zhiming
記事全体を表示
MPC5566 EMIOS SAOC mode Hi, I am setting EMIOS 17 to work as SAOC mode channel which uses bus C driven by EMIOS 8. However, SAOC mode is not working. Could you please help to check my code?  Thank you very much! Best Regards, Emily #include "MPC5566.h" /************ PWM_Period and PWM_Frequence should be changed together ************/ /* Define PWM period Counter value */ #define PWM_Period 16 #define FS_GPIO_EMIOS17 196 #define Commutation_Time_Channel FS_GPIO_EMIOS17 void initSysclk (void) { FMPLL.SYNCR.B.LOLRE = 0; /* 0: ignore loss of lock - reset not asserted. */ FMPLL.SYNCR.B.LOLIRQ = 0; /* 0: ignore loss of lock - interrupt not requested */ FMPLL.SYNCR.B.PREDIV = 1; /* 1: use incoming OSC 8MHz / 2 = 4 MHz */ FMPLL.SYNCR.B.MFD = 28; /* 28: VCO = 4 * (28+4) = 128 MHz */ FMPLL.SYNCR.B.RFD = 1; /* 1: divide by 2, Fsys = VCO / (2^1=2) = 64MHz */ while(FMPLL.SYNSR.B.LOCK != 1){} /* Wait for FMPLL to Lock */ FMPLL.SYNCR.B.RFD = 0; /* 0: divide by 1, Fsys = VCO / (2^0=1) = 128MHz */ } void initEMIOS(void) { EMIOS.MCR.B.GPRE= 7; /* Divide 128 MHz sysclk by 7+1 = 8 for 16MHz eMIOS clk*/ //EMIOS.MCR.B.GPRE= 63; /* Divide 64 MHz sysclk by 63+1 = 64 for 1MHz eMIOS clk*/ EMIOS.MCR.B.ETB = 0; /* External time base is disabled; Ch 23 drives ctr bus A */ EMIOS.MCR.B.GPREN = 1; /* Enable eMIOS clock */ EMIOS.MCR.B.GTBE = 1; /* Enable global time base */ EMIOS.MCR.B.FRZ = 1; /* Enable stopping channels when in debug mode */ } void initEMIOSch8(void) { /* EMIOS CH 8: Modulus Up Counter */ EMIOS.CH[8].CADR.R = PWM_Period - 1; /* Period will be 15+1 = 16 clocks (1 MHz) */ EMIOS.CH[8].CCR.B.MODE = 0x10; /* MPC555x: Modulus Counter (MC), internal clock */ EMIOS.CH[8].CCR.B.BSL = 0x3; /* Use internal counter */ EMIOS.CH[8].CCR.B.UCPRE=0; /* Set channel prescaler to divide by 1 */ EMIOS.CH[8].CCR.B.FREN = 1; /* Freeze channel counting when in debug mode */ EMIOS.CH[8].CCR.B.UCPREN = 1; /* Enable prescaler; uses default divide by 1 */ } void initEMIOSch17(void) { uint8_t EMIOS_Channel_Output; EMIOS_Channel_Output = Commutation_Time_Channel-179; /* Convert to EMIOS channel number compatible with EMIOS struct in MPC5566.h */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.MODE = 0x3; /* MPC555x: Mode is Single action output compare */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.BSL = 0x1; /* Use bus C */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.UCPRE = 0; /* Set channel prescaler to divide by 1 */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.FREN = 1; /* Stop (freeze) channel registers when in debug mode */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.UCPREN = 1; /* Enable prescaler; uses default divide by 1 */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.DMA = 0; /* FLAG assigned to Interrupt request */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.EDSEL = 1; /* Both edges triggering */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.FCK = 0; /* Filter clock select: EMIOS clock */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.IF = 0x1; /* Input filter: 8 filter clock periods */ EMIOS.CH[EMIOS_Channel_Output].CCR.B.FEN = 1; /* Flag enables interrupt */ SIU.PCR[Commutation_Time_Channel].R = 0x0E00; /* MPC555x: Initialize pad for eMIOS output */ } void main (void) { volatile uint32_t i = 0; /* Dummy idle counter */ uint32_t NextCmtPeriod=1000; initSysclk(); /* Set sysclk = 128MHz running from PLL */ initEMIOS(); /* Initialize eMIOS to provide 16 MHz clock to channels */ initEMIOSch8(); /* Initialize eMIOS channel 8 as modulus counter*/ initEMIOSch17(); /* Initialize eMIOS channel 17 as SAOC, using ch 8 as time base */ while (1) {i++; EMIOS.CH[17].CADR.R = EMIOS.CH[8].CCNTR.R + NextCmtPeriod; while(EMIOS.CH[17].CSR.B.FLAG != 1) { } NextCmtPeriod=NextCmtPeriod+2000; EMIOS.CH[17].CSR.B.FLAG = 1; } } Re: MPC5566 EMIOS SAOC mode Thanks a lot! Re: MPC5566 EMIOS SAOC mode Hi, yes, correct. BR, Petr Re: MPC5566 EMIOS SAOC mode Hi Peter, Thanks for your reply. I am wondering if I use EMIOS Chanel 16 to set bus D, SAOC of EMIOS Channel 17 can work only if EMIOS.CH[16].CADR.R>=EMIOS.CH[17].CADR.R? Best Regards, Emily Re: MPC5566 EMIOS SAOC mode Hi, if you want to use local counter bus for ch17, then ch16 (counter us D) have to be configured, not ch8 you have BR, Petr
記事全体を表示
新 MBDT 版本 (1.5.0) 上的引脚配置 我们正在将我们的开发迁移到 S32K3 系列的新版本 MBDT(1.5.0)。 我们需要为不同的功能配置一些引脚,例如LCU输出,并且发现新版本的S32config工具(1.7)不能像以前那样工作。 我们发现在 MCAL 组下创建了一个新的 PORT 组,并且 DRIVERS 下的旧 SIUL2-PORT 已被删除。在以前的版本中,每当在 PIN VIEW 中添加新的引脚时。PORT 组配置未更新。 在这个新版本中添加或更改引脚配置的正确程序是什么。 顺祝商祺! 回复:新 MBDT 版本 (1.5.0) 上的引脚配置 谢谢你的信息。现在我们可以以正确的方式配置引脚 我们还有一个问题,那就是 PWM 周期没有更新。所有 PWM 输出都冻结为 ConfigTool 中配置的默认 DT。 我们正在取消 EMIOS0 通道 1 和 2。 你对这个问题有什么想法吗?
記事全体を表示
Pin configuration on the new MBDT version (1.5.0) We are migrating our development to the new version MBDT for S32K3 family (1.5.0). We need to configure some pins for different functions such as LCU output and found that the new version of the S32config tools (1.7) doesn’t works as the previous one. We the that under the MCAL group a new PORT group has been created and the old SIUL2-PORT under DRIVERS has been removed. In the previous version whenever a new pin is added in the PIN VIEW. The PORT group configuration is not updated. What is the right procedure to add or change a pin configuration in this new version. Best regards. Re: Pin configuration on the new MBDT version (1.5.0) Hi, @Alfredo_Rubio , I am glad that you managed to correctly configure the Port and Pins flow.  Now related to the problem with the PWM period, in the toolbox there is a model that addresses the modification of both the Duty Cycle and the Period: s32k344_pwm_independent_ebt. The model has 2 PWM channels with a variable Duty Cycle and Period: The results will look like this: But when you change the Period of the PwmChannel_0 to 4000, as in the following picture: The results will look like this: By changing the value of the period in the second case, the signal parameters change can be observed. Following the example of this model, you can change the period of the signals configured in your application. I recommend you to try this approach of using the period change of a PWM signal. Let us know if there are any problems. Hope this helps, Dragos Re: Pin configuration on the new MBDT version (1.5.0) Thanks for the information.  Now we are able to configure the pins in the correct way We have an additional problem that is that PWM periode is not updated. All PWM outputs are frozen to the default DT configured in the ConfigTool.  We are unsing EMIOS0 channels 1 and 2. Do you have any idea on this subject. Re: Pin configuration on the new MBDT version (1.5.0) Hi, @Alfredo_Rubio , I highly recommend you check out the Release Notes of the latest release, version 1.5.0. I will summarize the new approach between Port and Pins: The toolbox offers support for configuring the on-board pins using the Port component, from the Peripherals Tool, together with the Pins Tool. The two must be used together as required by the implementation of the RTD (Real-Time Drivers) package that MBDT integrates. The configuration of the pins must be made according to the following information: For each functional group inside the Pins Tool, a Port container must be configured inside the Port component. Please see the screenshots below, the first one taken from the Pins Tool, and the second one from the Port component configuration inside the Peripherals Tool of a .mex file. By inserting the PortPin Mscr inside the PortPin configuration, the settings inside the Port component for that particular pin will be automatically populated as configured inside the Pins Tool. The name of the Pins Tool functional group must respect the following convention: PortContainer Name + ‘_MBDT’, ‘MBDT’ representing the name of the Functional Group from the Peripherals Tool, where all the components of the project are configured. Please check one of the default configurations provided inside the toolbox for an example on how Port and Pins must be configured. Additionally, you can find information related to Pins and Port tab in S32 Configuration Tool at the following Community thread link. Please let us know if you have other issues. Best regards, Dragos
記事全体を表示
S32K148 45 節を使用して phy レジスタの書き込みを読み取ることはできますか? SMIインターフェースを使用してPHYチップを制御する予定です。しかし、SDKに45項のphy制御インターフェースが見つかりません。 ユーザーマニュアルを読みました。S32K148第45条を支持することができます。 SDKにインターフェースはありませんか? Re:S32K148節45を使用してphyレジスタの書き込み読み取りを実行できますか? アーム2.2にS32DSを使用しています。 SDk は 3.0.0 です。3.0.0の例第45節の例はありません。 アームのS32DSに対する第45条のサポートはありませんか?
記事全体を表示