Enable SPI driver on nrf52840


cpmcparland@...
 

Has anyone successfully enabled spi driver on the nordic nrf52840_pca10056?  I2c seems
to work great, but I need both for an upcoming project.  I see the drivers are
in place, but its not enabled in the board dts file.  I'm guessing its still a bit experimental; but
would like to give it a try.  Any hints would be helpful.

Cheers,
RTISYS


Chettimada, Vinayak Kariappa
 

Hi,

 

The drivers are not experimental, you can use both I2C and SPI. Have you tried different instances of the peripherals?

i.e. I2C_0 and SPI_1 ?

 

If you are facing an issue, do provide details of your configuration, we will be glad to address defects, if any.

 

Regards,

Vinayak

 

From: devel@... [mailto:devel@...] On Behalf Of cpmcparland@...
Sent: Sunday, August 19, 2018 2:14 AM
To: devel@...
Subject: [Zephyr-devel] Enable SPI driver on nrf52840

 

Has anyone successfully enabled spi driver on the nordic nrf52840_pca10056?  I2c seems
to work great, but I need both for an upcoming project.  I see the drivers are
in place, but its not enabled in the board dts file.  I'm guessing its still a bit experimental; but
would like to give it a try.  Any hints would be helpful.

Cheers,
RTISYS


Justin
 

I believe that the SPI driver for NRF52 doesn't support DTS yet, and you have to configure it through the config files.  I'm not sure why that's the case and if something is preventing it from being supporting DTS?


cpmcparland@...
 

Justin, Vinayak,

Thanks, still digging into this.  So far, the cmake phase is not properly copying the
drivers into the library and failing before any make files are produced.  So, menuconfig
will not run on the project.  The driver CMakeLists.txt seems to be correct, but the value
CONFIG_SPI is not being set (I assume because of a DTS issue) and therefore the
source/library environment is not being properly generated by the initial project
cmake command.

Have performed the same operation with arduino_101 target and things work.  Don't
have one of those boards, so can't say that target code runs.  But, cmake and make
phase run successfully.  Have been comparing dts and dtsi files (should I be looking at
yaml as well?) between arduino_101 and nrf52840_pca10056 to look for an answer.
But, no joy as yet.  Any suggestions from the group?

Cheers,
Chuck


Chettimada, Vinayak Kariappa
 

Hi Chuck,

I do not understand “menuconfig will not run on the project”, you may want to check your toolchain requirements and/or make a clean build, check that cmake command for the board and application execute successfully.

When setting Kconfig options in prj.conf, one needs to ensure dependencies are taken care, which is something when using the targets “config” or “menuconfig” will take care when selecting Kconfig options.
Anyway, the build process will warn of any mismatch in the Kconfig options that you need to check for.

Alternatively, check your generated “.config” file if you have the required Kconfig options are selected.

Regards,
Vinayak 

On 22 Aug 2018, at 19:42, cpmcparland@... wrote:

Justin, Vinayak,

Thanks, still digging into this.  So far, the cmake phase is not properly copying the
drivers into the library and failing before any make files are produced.  So, menuconfig
will not run on the project.  The driver CMakeLists.txt seems to be correct, but the value
CONFIG_SPI is not being set (I assume because of a DTS issue) and therefore the
source/library environment is not being properly generated by the initial project
cmake command.

Have performed the same operation with arduino_101 target and things work.  Don't
have one of those boards, so can't say that target code runs.  But, cmake and make
phase run successfully.  Have been comparing dts and dtsi files (should I be looking at
yaml as well?) between arduino_101 and nrf52840_pca10056 to look for an answer.
But, no joy as yet.  Any suggestions from the group?

Cheers,
Chuck


cpmcparland@...
 

Vinayak,

Thanks for being persistent in looking at this issue.  Sorry for some confusion, I probably didn't state
the behavior I'm seeing very clearly.  At this point, the issue is that the cmake does NOT properly
complete when I include "CONFIG_SPI=y" in the prj.conf file.  My comment about menuconfig  was
just that, in my situation, it was not usable because the make files had not been created by the
cmake script that failed......sorry if that caused some confusion.

When I add CONFIG_SPI=y to the prj.conf file and do a clean cmake for BOARD=nrg52840_pca10056, I
get the following error from cmake:

CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__spi' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.

Cmake has created all directories in my target directory (......./build/nrf52840_pca10056/zephyr/drivers/......)
But, no source files have been copied into them from the kernel tree.

When I do the same operation, but targeting a different board (arduino_101), the directories get created
and, under target directory root (...../build/arduino_101/zephyr/drivers/spi), the correct board drivers have
been copied.  Cmake completes successfully and the make also completes successfully.

Is there a magic "CONFIG_XXX" that I just don't know about?

Regards,
Chuck


Chettimada, Vinayak Kariappa
 

Hi Chuck,

All that I am sayings is, do not modify your repository, do not add anything to prj,conf file.
execute cmake, then either use make or ninja for the target config or menuconfig. Then you get to the Kconfig options for SPI and I2C drivers, select and fill all necessary details like the IRQ priorities and pins etc.
Mind you if the dependencies are not filled correctly, you will need to start all over again (clean, seems some issue with unassigned values to Kconfig options).

Meanwhile, issue with cmake or make failing fatally for missing dependencies will be looked into, https://github.com/zephyrproject-rtos/zephyr/issues/9573

Sebastian / Ulf,
Seems the make menuconfig is un-usable if dependencies like pin assignments are missing after enabling SPI driver for nRF52840.

Regards,
Vinayak

On 23 Aug 2018, at 04:16, cpmcparland@... wrote:

Vinayak,

Thanks for being persistent in looking at this issue.  Sorry for some confusion, I probably didn't state
the behavior I'm seeing very clearly.  At this point, the issue is that the cmake does NOT properly
complete when I include "CONFIG_SPI=y" in the prj.conf file.  My comment about menuconfig  was
just that, in my situation, it was not usable because the make files had not been created by the
cmake script that failed......sorry if that caused some confusion.

When I add CONFIG_SPI=y to the prj.conf file and do a clean cmake for BOARD=nrg52840_pca10056, I
get the following error from cmake:

CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__spi' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.

Cmake has created all directories in my target directory (......./build/nrf52840_pca10056/zephyr/drivers/......)
But, no source files have been copied into them from the kernel tree.

When I do the same operation, but targeting a different board (arduino_101), the directories get created
and, under target directory root (...../build/arduino_101/zephyr/drivers/spi), the correct board drivers have
been copied.  Cmake completes successfully and the make also completes successfully.

Is there a magic "CONFIG_XXX" that I just don't know about?

Regards,
Chuck


Jan Van Winkel
 

Hi Chuck,

On top of CONFIG_SPI you have to specify which SPI interface your are using, that it is a NRFX SPI and the associated pins in your prj.conf.

Here is an example for the nrf52840_pca10056 I used in a pull request (#6826):
CONFIG_SPI=y
CONFIG_SPI_1=y
CONFIG_SPI_NRFX=y
CONFIG_SPI_1_NRF_SPIM=y
CONFIG_SPI_1_IRQ_PRI=10
CONFIG_SPI_1_NRF_SCK_PIN=3
CONFIG_SPI_1_NRF_MOSI_PIN=28
CONFIG_SPI_1_NRF_MISO_PIN=29

Regards,
Jan


On Thu, Aug 23, 2018 at 6:03 AM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
Hi Chuck,

All that I am sayings is, do not modify your repository, do not add anything to prj,conf file.
execute cmake, then either use make or ninja for the target config or menuconfig. Then you get to the Kconfig options for SPI and I2C drivers, select and fill all necessary details like the IRQ priorities and pins etc.
Mind you if the dependencies are not filled correctly, you will need to start all over again (clean, seems some issue with unassigned values to Kconfig options).

Meanwhile, issue with cmake or make failing fatally for missing dependencies will be looked into, https://github.com/zephyrproject-rtos/zephyr/issues/9573

Sebastian / Ulf,
Seems the make menuconfig is un-usable if dependencies like pin assignments are missing after enabling SPI driver for nRF52840.

Regards,
Vinayak

On 23 Aug 2018, at 04:16, cpmcparland@... wrote:

Vinayak,

Thanks for being persistent in looking at this issue.  Sorry for some confusion, I probably didn't state
the behavior I'm seeing very clearly.  At this point, the issue is that the cmake does NOT properly
complete when I include "CONFIG_SPI=y" in the prj.conf file.  My comment about menuconfig  was
just that, in my situation, it was not usable because the make files had not been created by the
cmake script that failed......sorry if that caused some confusion.

When I add CONFIG_SPI=y to the prj.conf file and do a clean cmake for BOARD=nrg52840_pca10056, I
get the following error from cmake:

CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__spi' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.

Cmake has created all directories in my target directory (......./build/nrf52840_pca10056/zephyr/drivers/......)
But, no source files have been copied into them from the kernel tree.

When I do the same operation, but targeting a different board (arduino_101), the directories get created
and, under target directory root (...../build/arduino_101/zephyr/drivers/spi), the correct board drivers have
been copied.  Cmake completes successfully and the make also completes successfully.

Is there a magic "CONFIG_XXX" that I just don't know about?

Regards,
Chuck


cpmcparland@...
 

Vinayak,

Thanks.  I thought that the creation the driver source directories was only done at cmake time.... so that's where I was looking
for a problem.  Clearly I was wrong about that.  Did just what you suggested using the arduino_101 board as target (that seems
to be the example always used) and things worked as you desicribed.  However all is not well yet with the nrf pca10056, so I
have taken a page from your note and am trying again from a clean dist.

I just cloned rc13 and am attempting to build the i2c_fujitsu_fram sample program.  Sourced the appropriate
zephyr_end.sh script.  Created build/arduino_101 in the sample
directory and executed cmake -DBOARD=arduino_101 ../..    All went well.  Also issued make command and sample
compiled and linked without a problem.  NO changes to anything in the repo - just cmake and make.

Then created a clean build/nrf52840_pca10056 directory in the sample directory and executed cmake -DBOARD=nrf52840_pca10056.
NO changes to the repo - just create directories and executed cmake.  REceived the following output and error:

cmake -DBOARD=nrf52840_pca10056 ../..
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.3", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
Zephyr version: 1.13.0
Parsing Kconfig tree in /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/Kconfig
Using /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/samples/drivers/i2c_fujitsu_fram/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
-- Cache files will be written to: /home/mcp/.cache/zephyr
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__i2c' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.


-- Configuring incomplete, errors occurred!

Any comments would be welcome.  Also, thanks for posting the menuconfig issue...am following that
closely.

Regards,
Chuck


Chettimada, Vinayak Kariappa
 

https://youtu.be/vioi4OsmB_U

Hope the above video helps :-)

Summary: Kconfig options for one board may require new dependencies be met for another board.

- Vinayak

PS: added users mailing list, hope helps them too.

On 28 Aug 2018, at 04:07, cpmcparland@... wrote:

Vinayak,

Thanks.  I thought that the creation the driver source directories was only done at cmake time.... so that's where I was looking
for a problem.  Clearly I was wrong about that.  Did just what you suggested using the arduino_101 board as target (that seems
to be the example always used) and things worked as you desicribed.  However all is not well yet with the nrf pca10056, so I
have taken a page from your note and am trying again from a clean dist.

I just cloned rc13 and am attempting to build the i2c_fujitsu_fram sample program.  Sourced the appropriate
zephyr_end.sh script.  Created build/arduino_101 in the sample
directory and executed cmake -DBOARD=arduino_101 ../..    All went well.  Also issued make command and sample
compiled and linked without a problem.  NO changes to anything in the repo - just cmake and make.

Then created a clean build/nrf52840_pca10056 directory in the sample directory and executed cmake -DBOARD=nrf52840_pca10056.
NO changes to the repo - just create directories and executed cmake.  REceived the following output and error:

cmake -DBOARD=nrf52840_pca10056 ../..
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.3", minimum required is "3.4")
-- Selected BOARD nrf52840_pca10056
Zephyr version: 1.13.0
Parsing Kconfig tree in /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/Kconfig
Using /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base
Merging /home/mcp/ZephyrProjects/zephyr_1.1.2/zephyr_latest/samples/drivers/i2c_fujitsu_fram/prj.conf
-- Generating zephyr/include/generated/generated_dts_board.h
-- Cache files will be written to: /home/mcp/.cache/zephyr
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__i2c' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.


-- Configuring incomplete, errors occurred!

Any comments would be welcome.  Also, thanks for posting the menuconfig issue...am following that
closely.

Regards,
Chuck


cpmcparland@...
 

Vinayak,

Great utube file.  Sorry for taking so long to get back on this, but wanted to check this out on the SPI
driver as well.  I might just be getting the hang of how this scheme works.....at least, I hope so!

I2C driver build worked exactly as your demo...not too surprising, but never hurts to verify.  I
also managed to get the SPI driver to work but, I had to change the setting of CONFIG_SPI_1 to
CONFIG_SPI_0 in the driver Kconfig file. I tried to do that in the prj.conf file, but it still failed. 
Making the change in Kconfig, however, worked.  I'm guessing there are some things that need to
be done early in the Kconfig file before prj.conf gets dealt with (?).

Will play around with compatible GPIO pins on the 52840 so that I can get both I2C_0 and SPI_0
working at the same time.

Thanks again for the video- things were really clear after that.

Cheers,
Chuck


Ulf Magnusson
 

On Fri, Aug 31, 2018 at 3:06 AM <cpmcparland@rtisys.org> wrote:

Vinayak,

Great utube file. Sorry for taking so long to get back on this, but wanted to check this out on the SPI
driver as well. I might just be getting the hang of how this scheme works.....at least, I hope so!

I2C driver build worked exactly as your demo...not too surprising, but never hurts to verify. I
also managed to get the SPI driver to work but, I had to change the setting of CONFIG_SPI_1 to
CONFIG_SPI_0 in the driver Kconfig file. I tried to do that in the prj.conf file, but it still failed.
Making the change in Kconfig, however, worked. I'm guessing there are some things that need to
be done early in the Kconfig file before prj.conf gets dealt with (?).

Will play around with compatible GPIO pins on the 52840 so that I can get both I2C_0 and SPI_0
working at the same time.

Thanks again for the video- things were really clear after that.

Cheers,
Chuck
Another random tip is that you can save a minimal configuration file
by pressing [D] in the menuconfig interface. The minimal configuration
file only lists symbols whose values differ from their default values,
and might give a better overview of the configuration.

The minimal configuration file might even work as a stand-in for
zephyr/.config, due to how the configuration system is set up at the
moment: When there are no changes to *_defconfig or *.conf files,
zephyr/.config gets read back in, and a new zephyr/.config is written
out. That new zephyr/.config will be "full". Don't count on that
though. :)

Cheers,
Ulf


cpmcparland@...
 

Vinayak, Jan, et. al.

Thanks again for your combined help on this.  Just ran into a pothole and I thinks its
a simple config issue on my part.  I have a simple spi write set up and it appears
to be functional.  Am using the following prj.conf.

ONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=1
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=7
CONFIG_SPI_0_NRF_MOSI_PIN=8
CONFIG_SPI_0_NRF_MISO_PIN=8
CONFIG_SPI_0_NRF_ORC=0xff

Having some problems w/debug, so I'm salting driver code with printk's.  Ok,
that's a bit of a hack, but will get debug up after this is running.  The problem is
that the driver is not returning on completion.  Its starting up and then it waits in
the sem take call -- as it should.  But, it never completes.  I have checked the
code that loads the event handler - that's executing at os start up.  I don't have
the ASYNC flag defined in config, so I would expect it to wait until the completion
event shows up from easyDMA.  Any suggestions?

Regards,
Chuck


Jan Van Winkel
 

Hi Chuck,

Looks like you configured MOSI & MISO to the same pin (8) is this intentional?
As far as I know the NRF52840 does not support 3-wire (shared MISO/MOSI pin) SPI mode.

Regards,
Jan

On Sat, Sep 8, 2018 at 2:54 AM <cpmcparland@...> wrote:
Vinayak, Jan, et. al.

Thanks again for your combined help on this.  Just ran into a pothole and I thinks its
a simple config issue on my part.  I have a simple spi write set up and it appears
to be functional.  Am using the following prj.conf.

ONFIG_STDOUT_CONSOLE=y
CONFIG_PRINTK=y

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=1
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=7
CONFIG_SPI_0_NRF_MOSI_PIN=8
CONFIG_SPI_0_NRF_MISO_PIN=8
CONFIG_SPI_0_NRF_ORC=0xff

Having some problems w/debug, so I'm salting driver code with printk's.  Ok,
that's a bit of a hack, but will get debug up after this is running.  The problem is
that the driver is not returning on completion.  Its starting up and then it waits in
the sem take call -- as it should.  But, it never completes.  I have checked the
code that loads the event handler - that's executing at os start up.  I don't have
the ASYNC flag defined in config, so I would expect it to wait until the completion
event shows up from easyDMA.  Any suggestions?

Regards,
Chuck


cpmcparland@...
 

Jan,

Thanks, missed that typo.  Fixed that, but same result.  For the moment,
I'm not worried about the data or behavior of the SPI device.  Just want to
see a driver transaction complete...data comes next.

Not very familiar with the "easy" part of easyDMA.  Do I need to configure
anything outside of the spim driver (besides the CS device and pin I'm handing to the
spi config structure)?

Regards,
Chuck


Jan Van Winkel
 

Chuck,

The only thing I needed to configure is the spi config struct (freq, spi mode of operation & cs) and it just worked out of the box.
But to be honest the only place where I used the NRF SPI is in the ILI9340 display driver[1] and that was a couple of months ago, maybe you can have a look at the SPI code in the display driver.

Regards,
Jan



On Sat, Sep 8, 2018 at 8:05 PM <cpmcparland@...> wrote:
Jan,

Thanks, missed that typo.  Fixed that, but same result.  For the moment,
I'm not worried about the data or behavior of the SPI device.  Just want to
see a driver transaction complete...data comes next.

Not very familiar with the "easy" part of easyDMA.  Do I need to configure
anything outside of the spim driver (besides the CS device and pin I'm handing to the
spi config structure)?

Regards,
Chuck