<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/104908/device-tree-translation-into-devicetree_generated-h-not-going-as-planned</link><description>I am developing in VSCode on an nRF52832 and trying to get peripherals setup correctly on my device. Using the device tree beyond the examples is proving difficult. I had one little issue that I made a really hacky solution to get a button working, but</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 01 Nov 2023 22:02:27 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/104908/device-tree-translation-into-devicetree_generated-h-not-going-as-planned" /><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/453587?ContentTypeID=1</link><pubDate>Wed, 01 Nov 2023 22:02:27 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e5fb2e5a-c803-4b78-87e0-56328aa9fd52</guid><dc:creator>Ryjan</dc:creator><description>&lt;p&gt;I just found an error I thought I had corrected 3 times already, but I must have deleted that changes. In my board definition file&amp;nbsp; Kconfig.defconfig I had my board defined as BOARD_CONFIG_BOARD_SMRTSW_V1_2 instead of BOARD_SMRTSW_V1_2. I&amp;#39;m not sure why it gave me the error it did. I&amp;#39;m guessing that it silently defaults to some other settings and ended up wanting to initialize a bunch of UART features. After fixing that, it compiled and ran. I saw my LEDs illuminate for the first time.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/453572?ContentTypeID=1</link><pubDate>Wed, 01 Nov 2023 19:03:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d5fca504-f7de-45b8-b12c-5830e7c2dbf5</guid><dc:creator>Ryjan</dc:creator><description>&lt;p&gt;The short version of my issue is I had another copy of my device tree in a location where West could find it, but the one I was editing was not the correct one.&lt;/p&gt;
&lt;p&gt;This came from several attempts at getting this working while being pulled off onto a different project daily. I had the device tree that I was editing in the project root under boards/ but the one the West could find was a temporary version I put in the Zephyr boards/ directory. That is why my pullups were all set to up for the GPIOs and even the pin number were incorrect. None of the PWM changes I made were changes to the correct file. I found this after using Nordic&amp;#39;s graphical tool for the device tree and noted that it was opening the copy I was not editing.&lt;/p&gt;
&lt;p&gt;This brought me back to the issue I hadn&amp;#39;t solved, but had forgotten about. I want to use an out of tree board definition. The seminar showed a couple of different ways to do it in NCS:&lt;/p&gt;
&lt;p&gt;&lt;img style="max-height:345px;max-width:698px;" height="345" src="https://devzone.nordicsemi.com/resized-image/__size/1396x690/__key/communityserver-discussions-components-files/4/NCS_5F00_out_5F00_of_5F00_tree_5F00_options.GIF" width="698" alt=" " /&gt;&lt;/p&gt;
&lt;p&gt;I&amp;#39;ve opted to use something that works for regular Zephyr by adding a few lines to my CMakeLists.txt file:&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;# BOARD_ROOT and BOARD need to be defined before finding Zephyr so the definitions are available before compilation
set(BOARD_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
set(BOARD smrtsw_v1_2)&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;I inserted this before&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="text"&gt;find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;After that line is too late to define the BOARD_ROOT and BOARD.&lt;/p&gt;
&lt;p&gt;By including the BOARD I no longer need to define on the command line if just using West and the code is easier for me to keep in one repo and distribute to my coworkers.&lt;/p&gt;
&lt;p&gt;Now the device tree is at least referenced correctly, but I haven&amp;#39;t gotten the code to run because there is an issue with the UART initialization. I had to include &amp;quot;zephyr,bt-uart = &amp;amp;uart0&amp;quot; in the chosen section of the device tree to allow it finish compiling, but I didn&amp;#39;t need or have that before. I don&amp;#39;t think my project needs the UART even for the RTT. Is that correct? Getting rid of all references to the UART in my device tree also does not make it happy. I found&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;# enable uart driver
CONFIG_SERIAL=y

# enable console
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;But even when disabling those my project still thinks I need UART stuff compiled to run. When I include all of that I get an initialization assert on line 330 of hci_init because a semaphore times out during initialization. It appears to be just the first bt_hci_cmd_send_sync() call to preform a reset. Seem logical for starting up the system the host controller for the Bluetooth. I was guessing that my addition of bt-uart was messing up the initialization because I don&amp;#39;t have some other dependency initialized for the bt-uart. However, I don&amp;#39;t think that I need any of that. So where else could something be asking for the uart to be setup. I would like to not include it. Am I correct that I do not need the UART to be initialized&amp;nbsp; to have a working RTT console?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/452822?ContentTypeID=1</link><pubDate>Fri, 27 Oct 2023 15:10:01 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1a657a83-8ece-42c0-a599-016152989ad3</guid><dc:creator>Ryjan</dc:creator><description>&lt;p&gt;I think I&amp;#39;ve found the cause. Once I get a solution going I&amp;#39;ll report back. As expected it looks like a something that I&amp;#39;ve missed, but this chat has helped me arrive at that conclusion.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/452522?ContentTypeID=1</link><pubDate>Thu, 26 Oct 2023 11:45:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:62935b30-9350-4099-bd8b-bc451dc46963</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;Hi again Ryjan&lt;/p&gt;
&lt;p&gt;You should still set the&amp;nbsp;&lt;strong&gt;CONFIG_NFCT_PINS_AS_GPIOS=y&lt;/strong&gt;&lt;strong&gt;&amp;nbsp;&lt;/strong&gt;in your NCS version, as this is the correct way to set NFCT pins as GPIOs in&amp;nbsp;most nRF Connect SDK versions.&lt;/p&gt;
&lt;p&gt;Unfortunately I don&amp;#39;t have much more to add to the PWM issue either, but let me know how the webinar went and whether or not it helped at all. I don&amp;#39;t see what&amp;#39;s set up incorrectly I&amp;#39;m afraid but will discuss this with a few colleagues to see if they have any suggestions on this as well. Do you have a Development Kit available, and if so do you also see the same issue with the PWMs there as well?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;One thing could be to try using the &lt;a href="https://nrfconnect.github.io/vscode-nrf-connect/"&gt;nRF DeviceTree extension in VS code&lt;/a&gt; to get a better view of what is enabled and not in your project. It gives a more user friendly display (GUI style) of the device tree and makes it easier to keep track of.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Simon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/452321?ContentTypeID=1</link><pubDate>Wed, 25 Oct 2023 14:29:55 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8e497816-2537-4b7e-89ca-bed99dc07ce6</guid><dc:creator>Ryjan</dc:creator><description>&lt;p&gt;I can&amp;#39;t remember why I eliminated the NFC setting at the issue, but I do see in devicetree_generated.h that it looks like there are flags set to disable it.&lt;/p&gt;
&lt;p&gt;&lt;pre class="ui-code" data-mode="c_cpp"&gt;/*
 * Devicetree node: /soc/nfct@40005000
 *
 * Node identifier: DT_N_S_soc_S_nfct_40005000
 *
 * Binding (compatible = nordic,nrf-nfct):
 *   $ZEPHYR_BASE\dts\bindings\net\wireless\nordic,nrf-nfct.yaml
 *
 * (Descriptions have moved to the Devicetree Bindings Index
 * in the documentation.)
 */

/* Node&amp;#39;s full path: */
#define DT_N_S_soc_S_nfct_40005000_PATH &amp;quot;/soc/nfct@40005000&amp;quot;

/* Node&amp;#39;s name with unit-address: */
#define DT_N_S_soc_S_nfct_40005000_FULL_NAME &amp;quot;nfct@40005000&amp;quot;

/* Node parent (/soc) identifier: */
#define DT_N_S_soc_S_nfct_40005000_PARENT DT_N_S_soc

/* Node&amp;#39;s index in its parent&amp;#39;s list of children: */
#define DT_N_S_soc_S_nfct_40005000_CHILD_IDX 14

/* Helper macros for child nodes of this node. */
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD(fn) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_SEP(fn, sep) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_VARGS(fn, ...) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_SEP_VARGS(fn, sep, ...) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_STATUS_OKAY(fn) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_STATUS_OKAY_SEP(fn, sep) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_STATUS_OKAY_VARGS(fn, ...) 
#define DT_N_S_soc_S_nfct_40005000_FOREACH_CHILD_STATUS_OKAY_SEP_VARGS(fn, sep, ...) 

/* Node&amp;#39;s dependency ordinal: */
#define DT_N_S_soc_S_nfct_40005000_ORD 81

/* Ordinals for what this node depends on directly: */
#define DT_N_S_soc_S_nfct_40005000_REQUIRES_ORDS \
	4, /* /soc */ \
	5, /* /soc/interrupt-controller@e000e100 */

/* Ordinals for what depends directly on this node: */
#define DT_N_S_soc_S_nfct_40005000_SUPPORTS_ORDS /* nothing */

/* Existence and alternate IDs: */
#define DT_N_S_soc_S_nfct_40005000_EXISTS 1
#define DT_N_INST_0_nordic_nrf_nfct DT_N_S_soc_S_nfct_40005000
#define DT_N_NODELABEL_nfct         DT_N_S_soc_S_nfct_40005000

/* Macros for properties that are special in the specification: */
#define DT_N_S_soc_S_nfct_40005000_REG_NUM 1
#define DT_N_S_soc_S_nfct_40005000_REG_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_REG_IDX_0_VAL_ADDRESS 1073762304 /* 0x40005000 */
#define DT_N_S_soc_S_nfct_40005000_REG_IDX_0_VAL_SIZE 4096 /* 0x1000 */
#define DT_N_S_soc_S_nfct_40005000_RANGES_NUM 0
#define DT_N_S_soc_S_nfct_40005000_FOREACH_RANGE(fn) 
#define DT_N_S_soc_S_nfct_40005000_IRQ_NUM 1
#define DT_N_S_soc_S_nfct_40005000_IRQ_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_IRQ_IDX_0_VAL_irq 5
#define DT_N_S_soc_S_nfct_40005000_IRQ_IDX_0_VAL_irq_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_IRQ_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_IRQ_IDX_0_VAL_priority 1
#define DT_N_S_soc_S_nfct_40005000_IRQ_IDX_0_VAL_priority_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_COMPAT_MATCHES_nordic_nrf_nfct 1
#define DT_N_S_soc_S_nfct_40005000_COMPAT_VENDOR_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_COMPAT_VENDOR_IDX_0 &amp;quot;Nordic Semiconductor&amp;quot;
#define DT_N_S_soc_S_nfct_40005000_COMPAT_MODEL_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_COMPAT_MODEL_IDX_0 &amp;quot;nrf-nfct&amp;quot;
#define DT_N_S_soc_S_nfct_40005000_STATUS_disabled 1

/* Pin control (pinctrl-&amp;lt;i&amp;gt;, pinctrl-names) properties: */
#define DT_N_S_soc_S_nfct_40005000_PINCTRL_NUM 0

/* Generic property macros: */
#define DT_N_S_soc_S_nfct_40005000_P_reg {1073762304 /* 0x40005000 */, 4096 /* 0x1000 */}
#define DT_N_S_soc_S_nfct_40005000_P_reg_IDX_0 1073762304
#define DT_N_S_soc_S_nfct_40005000_P_reg_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_reg_IDX_1 4096
#define DT_N_S_soc_S_nfct_40005000_P_reg_IDX_1_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_reg_FOREACH_PROP_ELEM(fn) fn(DT_N_S_soc_S_nfct_40005000, reg, 0) \
	fn(DT_N_S_soc_S_nfct_40005000, reg, 1)
#define DT_N_S_soc_S_nfct_40005000_P_reg_FOREACH_PROP_ELEM_SEP(fn, sep) fn(DT_N_S_soc_S_nfct_40005000, reg, 0) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, reg, 1)
#define DT_N_S_soc_S_nfct_40005000_P_reg_FOREACH_PROP_ELEM_VARGS(fn, ...) fn(DT_N_S_soc_S_nfct_40005000, reg, 0, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, reg, 1, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_reg_FOREACH_PROP_ELEM_SEP_VARGS(fn, sep, ...) fn(DT_N_S_soc_S_nfct_40005000, reg, 0, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, reg, 1, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_reg_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_interrupts {5 /* 0x5 */, 1 /* 0x1 */}
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_IDX_0 5
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_IDX_1 1
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_IDX_1_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_FOREACH_PROP_ELEM(fn) fn(DT_N_S_soc_S_nfct_40005000, interrupts, 0) \
	fn(DT_N_S_soc_S_nfct_40005000, interrupts, 1)
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_FOREACH_PROP_ELEM_SEP(fn, sep) fn(DT_N_S_soc_S_nfct_40005000, interrupts, 0) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, interrupts, 1)
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_FOREACH_PROP_ELEM_VARGS(fn, ...) fn(DT_N_S_soc_S_nfct_40005000, interrupts, 0, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, interrupts, 1, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_FOREACH_PROP_ELEM_SEP_VARGS(fn, sep, ...) fn(DT_N_S_soc_S_nfct_40005000, interrupts, 0, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, interrupts, 1, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_interrupts_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_status &amp;quot;disabled&amp;quot;
#define DT_N_S_soc_S_nfct_40005000_P_status_STRING_TOKEN disabled
#define DT_N_S_soc_S_nfct_40005000_P_status_STRING_UPPER_TOKEN DISABLED
#define DT_N_S_soc_S_nfct_40005000_P_status_ENUM_IDX 2
#define DT_N_S_soc_S_nfct_40005000_P_status_ENUM_TOKEN disabled
#define DT_N_S_soc_S_nfct_40005000_P_status_ENUM_UPPER_TOKEN DISABLED
#define DT_N_S_soc_S_nfct_40005000_P_status_FOREACH_PROP_ELEM(fn) fn(DT_N_S_soc_S_nfct_40005000, status, 0) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 1) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 2) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 3) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 4) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 5) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 6) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 7)
#define DT_N_S_soc_S_nfct_40005000_P_status_FOREACH_PROP_ELEM_SEP(fn, sep) fn(DT_N_S_soc_S_nfct_40005000, status, 0) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 1) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 2) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 3) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 4) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 5) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 6) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 7)
#define DT_N_S_soc_S_nfct_40005000_P_status_FOREACH_PROP_ELEM_VARGS(fn, ...) fn(DT_N_S_soc_S_nfct_40005000, status, 0, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 1, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 2, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 3, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 4, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 5, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 6, __VA_ARGS__) \
	fn(DT_N_S_soc_S_nfct_40005000, status, 7, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_status_FOREACH_PROP_ELEM_SEP_VARGS(fn, sep, ...) fn(DT_N_S_soc_S_nfct_40005000, status, 0, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 1, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 2, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 3, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 4, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 5, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 6, __VA_ARGS__) DT_DEBRACKET_INTERNAL sep \
	fn(DT_N_S_soc_S_nfct_40005000, status, 7, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_status_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_compatible {&amp;quot;nordic,nrf-nfct&amp;quot;}
#define DT_N_S_soc_S_nfct_40005000_P_compatible_IDX_0 &amp;quot;nordic,nrf-nfct&amp;quot;
#define DT_N_S_soc_S_nfct_40005000_P_compatible_IDX_0_STRING_TOKEN nordic_nrf_nfct
#define DT_N_S_soc_S_nfct_40005000_P_compatible_IDX_0_STRING_UPPER_TOKEN NORDIC_NRF_NFCT
#define DT_N_S_soc_S_nfct_40005000_P_compatible_IDX_0_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_compatible_FOREACH_PROP_ELEM(fn) fn(DT_N_S_soc_S_nfct_40005000, compatible, 0)
#define DT_N_S_soc_S_nfct_40005000_P_compatible_FOREACH_PROP_ELEM_SEP(fn, sep) fn(DT_N_S_soc_S_nfct_40005000, compatible, 0)
#define DT_N_S_soc_S_nfct_40005000_P_compatible_FOREACH_PROP_ELEM_VARGS(fn, ...) fn(DT_N_S_soc_S_nfct_40005000, compatible, 0, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_compatible_FOREACH_PROP_ELEM_SEP_VARGS(fn, sep, ...) fn(DT_N_S_soc_S_nfct_40005000, compatible, 0, __VA_ARGS__)
#define DT_N_S_soc_S_nfct_40005000_P_compatible_LEN 1
#define DT_N_S_soc_S_nfct_40005000_P_compatible_EXISTS 1
#define DT_N_S_soc_S_nfct_40005000_P_wakeup_source 0
#define DT_N_S_soc_S_nfct_40005000_P_wakeup_source_EXISTS 1
&lt;/pre&gt;&lt;/p&gt;
&lt;p&gt;The line that I think should make the difference is &amp;quot;#define DT_N_S_soc_S_nfct_40005000_STATUS_disabled 1&amp;quot; so it appears to be disabled.&lt;/p&gt;
&lt;p&gt;As a note , this is a custom board definition and I&amp;#39;m planning on attending the webinar later today on the subject of building custom boards. I the end, I expect it to be a syntax error on my part in the devicetree, but I just don&amp;#39;t see it yet.&lt;/p&gt;
&lt;p&gt;Concerning the PWM channels, right not I have just a single call to select a output level that is set once, so I can verify that I have it working. Since I am using a custom board, the pins are different than the ones in the developer kit board for the nRF52832. The issue I see so far with them is that devicetree_generated.h does not seem to correctly reflect the devicetree I setup. Only PWM0 is used and the channels are not as set. Unfortunately there is not a lot off error checking in the devicetree toolchain so my issues fail silently without giving me very many clues as to where the issue lies.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/452146?ContentTypeID=1</link><pubDate>Wed, 25 Oct 2023 07:17:40 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7adecad4-d856-4cc0-b3aa-6724ca3a3a5d</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;The&amp;nbsp;&lt;span&gt;&lt;strong&gt;CONFIG_NFCT_PINS_AS_GPIOS&lt;/strong&gt; is only deprecated in the latest (main branch) version of the nRF Connect SDK, so the device tree addition should indeed not matter if you&amp;#39;re using any SDK version prior to NCS 2.4.2.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;So adding the&amp;nbsp;&lt;strong&gt;CONFIG_NFCT_PINS_AS_GPIOS=y&lt;/strong&gt; does not do anything to fix the P0.09 and P0.10 on your end?&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Regarding your PWM question,&amp;nbsp;&lt;strong&gt;OUT&amp;nbsp;&lt;/strong&gt;in I.E.&amp;nbsp;&lt;strong&gt;NRF_FUN_PWM_OUT0&amp;nbsp;&lt;/strong&gt;refers to it being an output pin. Are the pins you&amp;#39;re using for PWM connected to LEDS, and that&amp;#39;s why you&amp;#39;re expecting lights to fade? Note that the LEDs on the DK is connected to P0.17-P0.20, so if you&amp;#39;re using the onboard LEDs you need to use these pins.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;span&gt;Best regards,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Simon&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/451818?ContentTypeID=1</link><pubDate>Mon, 23 Oct 2023 17:37:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:200267ee-1eb9-4232-89dd-93df0586a91c</guid><dc:creator>Ryjan</dc:creator><description>&lt;p&gt;I started this project in February so it should not be the latest. I did try adding &lt;strong&gt;&amp;amp;uicr { nfct-pins-as-gpios; };&lt;/strong&gt; into the device tree and remove CONFIG_NFCT_PINS_AS_GPIOS=y and my hack and the problem came right back. I looked through the changlogs for the different SDKs and could not find a reference to that change in them.&lt;/p&gt;
&lt;p&gt;I am using a switch on pin 0.10 that has a pull down. Pins 0.03 and 0.08 are both using pull ups and have opposite logic.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/451782?ContentTypeID=1</link><pubDate>Mon, 23 Oct 2023 15:00:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:0f07b489-34d0-455f-a335-45799f422809</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;&lt;span&gt;&lt;strong&gt;CONFIG_NFCT_PINS_AS_GPIOS=y&lt;/strong&gt;&amp;nbsp;was recently deprecated, and we recommend using the devicetree for the most recent NCS releases. What NCS version are you working on here? If it doesn&amp;#39;t help to set NFC pins as GPIOs, can you try using other pins than the NFC pins just to make sure.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Which of the pins is it that has inverted logic compared to the others? I&amp;#39;ll take another look if that doesn&amp;#39;t help either.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Best regards,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Simon&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/451746?ContentTypeID=1</link><pubDate>Mon, 23 Oct 2023 13:32:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6087a298-1e5a-4d12-9378-18e477c5650b</guid><dc:creator>Ryjan</dc:creator><description>&lt;p&gt;I spent quite a bit of time trying to blame it on an NFC pin issue, but ultimately ruled it out. I edited my prj.conf to include this: CONFIG_NFCT_PINS_AS_GPIOS=y and did some testing. In the end I determined that it was not the source of my issue with the button, but I may have incorrectly concluded that. Do I need to also have &lt;strong&gt;&amp;amp;uicr { nfct-pins-as-gpios; };&lt;/strong&gt; in my device tree as well?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Device Tree translation into devicetree_generated.h not going as planned</title><link>https://devzone.nordicsemi.com/thread/451684?ContentTypeID=1</link><pubDate>Mon, 23 Oct 2023 11:19:40 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3fb92ca8-e533-40e2-a0f8-a20bf672ac3c</guid><dc:creator>Simonr</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;The first thing that comes to mind when reading this case is that you&amp;#39;re using pins P0.09 and P0.10 as PWM and buttons. By default these pins are set as NFCT pins and thus won&amp;#39;t work as expected when used as GPIOs. This would explain why one button is inverted and why one of the PWMs doesn&amp;#39;t work as expected.&lt;/p&gt;
&lt;p&gt;You&amp;#39;ll need to use the Devicetree to configure NFCT pins as GPIOS with&amp;nbsp;&lt;strong&gt;&amp;amp;uicr { nfct-pins-as-gpios; };&amp;nbsp;&lt;/strong&gt;in your project.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Simon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>