I'm using the Segger nRF52840-DK and I want to add support for SPI?

[john3909]

I'm using the nRF52840-DK evaluation software from Segger. I want to add NAND Flash support, so I want to add an SPI interface. I have looked at the example in nRF5SDK160098a08e2 and that works nicely on my board, but I'm having difficulty moving that SPI example to the nRF52840-DK project as there are dependencies on Integration, module and components folders. isn't there a much simpler way to just add SPI support like there is when using ST Micro Cube IDE? I did manage to have a successful build with nrfx version of SPI, but the driver won't work correctly on my board.

I'm using the latest version of Segger Embedded Studio.

Regards,

John

[Karl Ylvisaker]

Hello John,

but I'm having difficulty moving that SPI example to the nRF52840-DK project as there are dependencies on Integration, module and components folders.

Yes, the drivers and libraries of the SDK is located in these folders, and you will have to add them to your "preprocessor included directories" so that they are available to the preprosessor when you are going to compile your project. If you are working in Segger Embedded Studios, this is done by right-clicking the project name in the project explorer view and selecting options..->preprocessor->User Include Directories while in the common configuration.
In your case, you mention that you are using the ST Micro Cube IDE, which I personally have never worked with - a brief google search on the topic yielded this forum post where they seem to discuss the relevant process for the ST Micro Cube IDE. In essence, you need to provide the IDE with the paths to your included files(*.h files) and you will have to include the source code files(*.c) in the project.

I did manage to have a successful build with nrfx version of SPI, but the driver won't work correctly on my board.

Could you elaborate what you mean by this - you are able to compile and flash the project, but it does not behave as expected? Or does something else happen before you are able to run it? Please be as specific as possible.

Please let me know if this does not answer your question,

Best regards,
Karl

 

[john3909]

So let me give you an example of how crazy this is. I start by copying

modules/nrfx/drivers/include/nrfx_spi.h

modules/nrfx/drivers/include/nrfx_spim.h

modules/nrfx/drivers/src/nrfx_spi.c

modules/nrfx/drivers/src/nrfx_spim.c

modules/nrfx/hal/nrf_spi.c

modules/nrfx/hal/nrf_spim.c

The I add the following to the preprocessor include directories

$(ProjectDir)/../../../modules/nrfx/drivers

$(ProjectDir)/../../../modules/nrfx/drivers/include

$(ProjectDir)/../../../modules/nrfx/hal

I do a build and get a compile error nrfx.h is missing

I add the following to the preprocessor include directories

$(ProjectDir)/../../../modules/nrfx

I build again, and I get a compile error nrfx_config.h is missing

Do you see how crazy this is???? There has to be a much simpler way, but I just don't see it.

Regards,

John

[Karl Ylvisaker]

Hello John,

john3909 said:

Setting up the clock for the SPI peripheral, setting up pin configuration, enabling the SPI peripheral, setting up the SPI registers, etc. In ST Micro, I don't have to do any of this, it is done automatically for me.

There is unfortunately no way to add all this like shown in the ST Micro video. I understand how you may see this as backwards, but with the versatility of our SoC's it is unfeasible to create a code-generator that will fit the different requirements of all our customers. I am sorry to disappoint you, but you will indeed have to do some "low level grunt work" - however, I would argue that most of the really low level work is already taken care of by the different drivers, so in reality you will not have to do any register manipulation yourself.

john3909 said:

Do you see how crazy this is???? There has to be a much simpler way, but I just don't see it.

I think you are going about this at a harder route than necessary. What you describe seems to be the effort of copying the select parts of the SDK that you need into a separate project - when you instead could provide the paths to the SDK directories to the preprocessor directly.
To avoid having to go through the process you describe, I would recommend that you use an existing example from the SDK as the base for your project. This way, you will not have to add these paths yourself, because the Segger Project file already have included the relative paths to the different module directories in the SDK.
All you then would have to do is add the specific source files into your project that you would like to use.

For instance, if you begin with the nrfx_spim example referenced earlier. If you then require for example TWIM as well, you would only have to add the nrfx_twim source file and relevant sdk_config parts to your project to begin working with it.

Best regards,
Karl

[john3909]

Karl Ylvisaker said:

I think you are going about this at a harder route than necessary. What you describe seems to be the effort of copying the select parts of the SDK that you need into a separate project - when you instead could provide the paths to the SDK directories to the preprocessor directly.

Even if I just updated the preprocessor include path to include the SPI example project, you still have to copy a bunch of C files and update the GCC linker script because your SDK uses custom sections. I gave you a link to my project, so show me how easy it is to update the GCC linker script. It isn't simple.

Regards,

John

[john3909]

Karl Ylvisaker said:

I think you are going about this at a harder route than necessary. What you describe seems to be the effort of copying the select parts of the SDK that you need into a separate project - when you instead could provide the paths to the SDK directories to the preprocessor directly.

Referencing preprocessor include folders in an external project isn't possible because of strict code review and traceability required for medical device certification.

Karl Ylvisaker said:

There is unfortunately no way to add all this like shown in the ST Micro video. I understand how you may see this as backwards, but with the versatility of our SoC's it is unfeasible to create a code-generator that will fit the different requirements of all our customers

This makes no sense to me. For each peripheral, there are the primary HAL files and their associated dependent files. A simple script could copy these to a new project and update the GCC linker script file with a patch tool. As a minimum, you could just list the files and explain the changes needed for the GCC linker script file. This is not rocket science.

Regards,

John