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

[john3909]

Hi Karl,

I continued this process of copying the missing file and rebuilding until the compiler was happy. In the end, 78 files were copied from the SPI examples project. This took the better part of a whole day. What a waste of time. Now I have some linker errors where it is complaining about .nrf_balloc will not fit in region 'UNPLACED_SECTIONS'. Clearly the GCC linker script file needs to be updated because the SPI example project used some custom sections. Can you understand my frustration working with your SDK? All of this makes a developer's life much more difficult. Here is my Segger project in it's current form.

https://drive.google.com/file/d/1fbFMxvhs5wUW0rStkpe2RS4XUjvhYOET/view?usp=sharing

I don't want to learn about GCC linker scripts, so I'm hoping that someone at Nordic will understand how to fix this, or show me an easier way of adding SPI to an existing project. In every other development tool I have used, this is simply selecting a checkbox and generate code and rebuilding. No more than 5 minutes total.

BTW, Segger technical support suggested starting with your SPI example and adding in emFile files. After 3 iterations, we are no closer to getting that project to work either.

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]

With Segger technical support, we started with your SPI example, and then added emFile files and we haven't got that working either. When you say "you would only have to add the nrfx_twim source file and relevant sdk_config parts to your project to begin working with it", you don't say which source files. For example, adding SPI comms to the nRF52840-DK project, I had to add 78 files just to get a clean compile. Why do you use custom sections in files like nrf_balloc.c? Now I have to update the GCC linker script as well.

I shouldn't have to start with one of your examples. If I have a project, then there should be a simple way to add code for any processor peripheral.

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.

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