Attachments (0)
Nordic Case Info
  • Case ID: 305051
Options

How to create a custom yaml file

Meh

I'm trying to initialize an Analog Devices sensor when I used the "adi,adx1345.yaml" as the configuration even though it's not the adx1345. (Previous ticket here) It did build, yet the sensor doesn't respond on the MISO bus. I think it is due to the lousy configuration file.

However, when I try to use the basic "spi_device.yaml", I get multiple errors, and even after setting a proper value for these, I'm getting others.

I'm using NCS v2.2 and working with nRF52840 and nRF5340 mainly.

New configuration and errors(Nrf52830 OVERLAY):

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
&spi3 {
adi_foo: adi_foo@0{
// compatible = "adi,adxl345";
compatible = "spi-device";
reg = <0>;
spi-max-frequency = < DT_FREQ_M(8) >; //even when I'm switching DT_FREQ to 8000000 it doesn't matter
duplex = < 0 >;
frame-format = < 0 >;
label = "adi_foo";
// friendly-name = "adi_foo";
};
};
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I'm getting errors following misconfigured duplex, max frequency. Any ideas on how to solve it? 

  • 0

    Hello Meh,

    To your question and post here regarding a SPI based sensor -- I assume an accelerometer? -- will you share the specific build time errors you're seeing?  I don't find those in your code excerpt of thirteen lines above.  Those specific errors could be most helpful.

    Are you able to share the part number of the sensor you're bringing up?  I have read your prior ticket but I don't see a specific sensor mentioned there.  Might help in trouble-shooting to know this, even if the issue you're facing is not ultimately sensor specific.

    Recently I was working and able to bring up a Kionix accelerometer on a SPI bus, in a Zephyr based application.  For this my work depends on device tree source and YAML bindings files.  While not an expert, there may be some help I can offer you based on some of the problems I faced and had to overcome.

    One strange thing I noticed is that despite Zephyr RTOS sensor API and conventions, I needed in my application to declare and initialize a GPIO outside of the sensor driver code, to provide for the chip select signal to my sensor.  It was not sufficient to have a `drdy-gpios` or `cs-gpios` property in sensor node of my application's DTS overlay file.  That alone did not generate a working CS line.  But it sounds like you are facing errors at an earlier-than-run-time stage.

    - Ted

  • 0 in reply to tedhavelka

      My sensor is not an accelerometer but rather a certain AFE. I'm getting errors in the same format as the previous ticket but with different fields as issues - A misconfigured node property.

    To start with something stable, I've already used the "Arduino SPI" port - with CS defined. The funny part is - the firmware builds well. I'm clueless.

  • 0 in reply to Meh

    you say "the firmware builds well" but that you're getting errors "in the same format as the previous ticket".  The errors in your previous ticket are compiler errors.  So is the firmware actually building, or are your errors happening at run time?

    If you're finding unexpected run time behavior, are you able to probe SPI bus lines with an oscilloscope or Saleae type probe?

    I'm going to take it that your custom app is erring out at compile time, but an Arduino SPI port / sample app builds correctly.

    In the case that you're seeing those `DT_N_S_SOC_S_SPI_ . . . not declared here` errors for a SPI-bus-connected sensor, I would double check your bindings file(s) for this sensor.  Zephyr RTOS spi-device.yaml describes four node properties, but says that only `reg` and `spi-max-frequency` are required.  Your error messages from the prior ticket indicate to me that your sensor -- if the AFE sensor code throws same compiler errrors -- expects SPI's `duplex` and `frame-format` node properties to be called out in your overlay or other project DTS files, even if they're not required properties per Zephyr's generic SPI device bindings file.

    Are you able to open up your project's build artifacts?  If you're building a Zephyr based app for a single core microcontroller, you should be able to find some useful summary info in an intermediate build file in [application_root]/build/zephyr/zephyr.dts.  You may already know this, but this file holds the final summary and "winning selections" of all the parsed device tree source in your app's project.  I have tracked down a number of bugs and incorrect device tree property settings by reviewing this file as I build and develop new features.

    It appears that you're already writing your own bindings and device tree files.  In your project I would double check that the overlay file for the AFE sensor contains correctly formatted, and correctly assigned node properties for your AFE.  If the node property such as `duplex` appears in your AFE's device tree node in `[application_root]/build/zephyr/zephyr.dts` then there should be no error of the form `DT_N_S_SOC_S_SPI_ . . . not declared here` for that particular node property.

    Some of the comments in Zephyr RTOS' general SPI device bindings file linked to in this reply, mention that properties like `frame-format` should be assigned a macro for their value, rather than the numeric values to which those properties can be set.  To better understand how vendors author their sensor overlay files, I find some reasonable DTS overlays by searching Zephyr's source tree starting at `zephyr/samples`.  My text search pattern (grep -nr spi-max-freqency ./*) returns almost twenty overlay files.  A dozen of these live in `zephyr/samples/drivers`.  And I can see some of them call out and assign values to optional, and not just required SPI bindings properties.

    This reply does not solve your problem but I would be curious to see what that zephyr.dts file contains for the AFE device node.  If your build process errors out before this file is generated, I expect you can at least get a little further by adding any missing node properties to your overlay, those which appear one per line in the errors at the top of your previous ticket.  Their assigned values could be wrong, but if the DTS syntax is correct then the device tree compiler should generate those missing, "not declared" symbols.

    Once you overcome those "not declared" errors, the values to assign the declared properties should be presented in the datasheet of your AFE, in a section about SPI or digital interfacing of that part.

    - Ted

  • +1 in reply to tedhavelka

    Hey, sorry for the late response.

    However, in my case - using one of the adi's yamls did the trick eventually - when I looked at the definition, I realized it's pretty agnostic as it is.

    Thanks for all the helpers :)  

  • 0 in reply to Meh

    Hello Meh,

    While I don't fully understand your solution I'm glad you solved your SPI YAML problem.  No worries about a response some days out.  As the developer posting the issue to solve it's up to you when and whether to reply.

    Good luck to you in your next stages of firmware development!  Stay safe,

    - Ted

Terms of service