Hello Nie, First you have a limitation in the fact the ethernet driver (eth_mcux) for this board is implemented as single instance, you need 2 instances (new feature implementation). I’m also not sure

Hello Alessandro, nxp_hal was moved outside zephyr repo, you need to do “west update” to get the external repo. Zephyr project will know how to link that repository. If you have changes made there in

Will not work in current mainline, unless you apply https://github.com/zephyrproject-rtos/zephyr/pull/17984 Andrei Gansari

Hello Flavio, From what you describe, most probably you have an old version of SEGGER JLink on your host machine. I have the following version on my machine: SEGGER J-Link Commander V6.46c (Compiled J

Hello, Yes, my example was hardcoded in regard to port and pin number. Your example makes them configurable via dts, while code remains the same. I only have to point another thing: the generated macr

#defines

Hello Bo, We have a general help page for Device Tree: https://docs.zephyrproject.org/latest/guides/dts/index.html In your particular case, you need to set port b pin 22 as output. Device Tree: The pu

#defines

Hello Kai, I’ve previously used -DCONFIG_NO_OPTIMIZATIONS=y when compiling to use O0. (default zephyr_sdk, should work for gcc-arm-none-eabi) Have a look at zephyr\cmake\compiler\gcc\target_optimizati

Hello Aymeric, If you don’t mind using the bare metal driver in your application as Maureen suggested, there is also i.MX RT 1050 EVKB board that does support Ethernet and has an unpopulated CAN conne

Hello everyone, I have a question regarding TEST_RANDOM_GENERATOR. When building networking samples for boards with entropy devices is get the warning: warning: TEST_RANDOM_GENERATOR (defined at subsy