Not sure if anyone on here can help guide me through the apparent minefield I am currently facing. Its seems like a simple task on the face of it, but I’m making a bit of a mess of it.
I’m a relative newcomer to Zephyr/nRF Connect SDK/VSC, so fumbling my way around a bit.
I’m currently trying to get some code together to enable me to read/write times to my PCB85063A RTC. I know the hardware is working, because I’ve tested it on my Cypress DevKit (long story here). But I can’t seem to get anything out of it when I hook it up to my nRF52-DK.

Essentially I grabbed Jared’s pcf85063a.c and pcf85063a.h files and added them directly into my project (yep, probably not the best way to go about it, but I’m still feeling my way here!). I added an overlay file so I could reference the device via DeviceTree:

&i2c0 { /* SDA P0.26, SCL P0.27 */
pcf85063a@51 {
compatible = "nxp,pcf85063a";
label = "PCF85063A";
reg = <0x51>;
};
};

This kicked up some errors in the overlay file. The first associated with pcf85063a@51. It was saying something like:
Only i2c nodes accepted in /soc/i2c@40003000/.

The second was associated with:
compatible = "nxp,pcf85063a" - Unknown node type "nxp,pcf85063a"

Also, when I try and add CONFIG_PCF85063A=y to my .proj file, it says:
attempt to assign the value 'y' to the undefined symbol PCF85063A

Everything seems to build without errors if I remove the CONFIG_PCF85063A=y reference. But when I try and do something simple in my code like:
`const struct device *dev = device_get_binding(“PCF85063A”);

if (dev == NULL) {
	printk("Could not get PCF85063A device\n");
	return;
}`

I get the “Could not get PCB85063A device” statement.

I could do with a bit of help stepping my way through the set up process if anyone has gone down this path before and can help out someone on their L-plates!

Cheers,
Mike

    5 days later

    jaredwolff Thanks Jared. I did read that, but its only added to my confusion. I probably need to take a few steps back and get my head around KConfig proj.config, module.yml, devicetree, overlay files, etc, etc and how these are all used to set up device drivers.

    I wasn’t able to follow your instructions step for step as I’m using the nRF Connect SDK add-on in VSC to do all my firmware development, and so the references to west, west update and manifest, west.yml etc, got me a bit confused.

    Got any pointers on where someone with my limited understanding of our all the components that are working together “under the hood” in the nRF Connect/VSC environment, can read up on these things and better understand it? It seems pretty crucial to getting any new hardware device set up, but there doesn’t seem to be an “Idiots Guide” anywhere I can find
    Cheers,
    Mike

      maustin-redant yea adding it to an NCS can be confusing especially if you’re starting from scratch.

      I would place the manifest entry in nrf/west.yml here:

          - name: openthread
            repo-path: sdk-openthread
            path: modules/lib/openthread
            revision: 02e61a2edd80417e9b8f9a5f4c1b2dad4ac486b4
         - <PUT IT  HERE!> <=======
      
        # West-related configuration for the nrf repository.
        self:
          # This repository should be cloned to ncs/nrf.
          path: nrf
          # This line configures west extensions which are currently only
          # for internal use by NCS maintainers.
          west-commands: scripts/west-commands.yml

      Then run a west update which will fetch the driver and make it available for you to use.

      Hope that helps!

        jaredwolff Thanks again Jared. Found the west.yml file and have updated that, but…and bear with me here if this seems like a “how the hell did this guy get this far” type question, but where do I do the west update?

        I’ve tried all sorts of terminal window in all sorts of directories on my nRF Connect SDK installation, and every time I try “west update” I get an error saying “The Command west was not found”

        I’m doing all my development from within Visual Studio Code, with the nRF Connect SDK for Visual Studio Code extension, so haven’t had to directly interact with west at any stage, hence my total lack of understanding

        Cheers,
        Mike

          maustin-redant you may have to refer to Nordic’s documentation. If you can find a way to open up a terminal window through the plugin, that should include the path to west.

            jaredwolff OK, I’ve made some progress. I ended up completely removing VSC and the Nordic SDK and nRF Connect Manager and starting afresh. Things had gone pear shaped somehow and I had no idea how to reverse what I have done so it seemed like the easiest option

            So, I was able to update west.yml and do a west update. Saw this pop up when it was doing its thing:

            --- pcf85063a: fetching, need revision master

            And I can see the pcf85063a sub-folder in my v1.9.1 folder, so its obviously grabbed what it needed.

            If I then build any of my projects, I see this pop up in the terminal window:

            `– Found assembler: C:/Nordic/v1.9.1/toolchain/opt/bin/arm-none-eabi-gcc.exe
            CMake Warning at C:\Nordic\v1.9.1\zephyr\CMakeLists.txt:764 (message):
            No SOURCES given to Zephyr library: ..pcf85063adrivers__rtc

            Excluding target from build.`

            Not sure if that is significant or not.

            I then added the #include for the pcf85063a.h header to my code, the CONFIG_PCF85063A=y to my prof.config and the mods to the board file and did a build. Again, I saw this pop up in the terminal window:

            `CMake Warning at C:\Nordic\v1.9.1\zephyr\CMakeLists.txt:764 (message):
            No SOURCES given to Zephyr library: ..pcf85063adrivers__rtc

            Excluding target from build.
            `
            But everything seems to compile OK, so that’s a leap forward! I haven’t actually attempted to use any of the API’s to access my RTC as yet, but when I get some time (and hopefully it will work!) I’ll get back with an update.

            Thanks for your assistance @jaredwolff. This stuff is all a bit confusing/confronting for someone experiencing it for the first time!

            Cheers,
            Mike

            Success!

            Got this spewing out the terminal window now :-)

            16:21:27, Sunday, 22-May-2022
            16:21:28, Sunday, 22-May-2022
            16:21:29, Sunday, 22-May-2022
            16:21:30, Sunday, 22-May-2022
            16:21:31, Sunday, 22-May-2022
            16:21:32, Sunday, 22-May-2022
            16:21:33, Sunday, 22-May-2022
            16:21:34, Sunday, 22-May-2022
            16:21:35, Sunday, 22-May-2022
            16:21:36, Sunday, 22-May-2022
            16:21:37, Sunday, 22-May-2022
            16:21:38, Sunday, 22-May-2022
            16:21:39, Sunday, 22-May-2022
            16:21:40, Sunday, 22-May-2022
            16:21:41, Sunday, 22-May-2022
            16:21:42, Sunday, 22-May-2022
            16:21:43, Sunday, 22-May-2022

            BTW, I added this to an overlay file:

            &i2c0 {
            pcf85063a@51 {
            compatible = “nxp,pcf85063a”;
            reg = <0×51>;
            label = “PCF85063A”;
            };
            };

            Rather than making the mods to the board file in my project.

            Cheers,
            Mike

            Terms and Conditions | Privacy Policy