Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

modifying nrf_spim p10056 to a p10056e build


I am having quite a frustrating time trying to make SPI drivers compile into a 52811 project I already started, so I thought I'd back off, and try to just get an SPI example project running (simulated) on the 52840-DK 

Of course there are exactly zero example projects for SPI that are even supplied in the SDK to target 52811 in emulated mode on a 52840-DK (Not a great look...) so I've jumped in to modify nrf_spim for p10056 into p10056e.

now first up, this example uses SPI instance 3 while the 52811 only has instances 0 and 1... so I modified this in the 52840 project, and got that at least compiling... (mod sdk_config.h to target instance 1 and turn off extended features.., them modified main.c to call for instance 0 instead of 3, and not use the dcx version of the transfer function and comment out references to extended features in the peripheral setup... ) all good - that compiles. I also modified the example to use port pins that actually exist on the 52811 (and are the actual pins I want to use on the custom board some day when I'm no longer stuck on such a basic fundamental simple thing as compiling an example project form the SDK for such a simple commonly usef peripheral as SPI)

Then to do the compile target transfer... I tried to follow the project migration instructions from nordic, and think I did OK (discovered a whole pile of things for Segger Embedded Studio project migration that are completely missed in the official migration instructions... like the whole soft FPU, linker heap size, stack size, etc -  but hey at least the differences were in existing projects that had 10056 and 10056e targets available so that was something!) 

But now I'm stuck with some complaint about "BSP_BUTTON_ACTION_LONG_PUSH" not being defined in bsp.c, this is caused because of something called BSP_DEFINES_ONLY being set to 1 somewhere (segger embedded studio "go to definition" function  can't find it, but hey... the compiler and the live code highlighter sure can!), which causes the button action define I'm missing to never be made... BUT different rules in a section of bsp.c cause code that relies on that define to be enabled... hence the fail to compile....  I can go in and modify the preprocessor commands so that the problematic code lines also get killed when the define they are referencing gets killed, but then I get more flow-on errors in bsp.c

And with this, quite frankly, I'm not convinced now that it's even possible to target an SPI example project port to either a real 52811 or an emulated one on the SDK.. at least without some surgery inside the SDK. Which makes me wonder if nordic themselves, letalone anyone else, has even used the SPI peripherals in a 52811 yet... 

So anyway - if you take this attached stuff and drop it into SDK15.3/examples/peripheral/nfx_spim then load up the project with segger embedded studio, you can also have all the fun I'm having... I'd be very happy to see an example of an SPI peripheral master being configured to run on an 82511 (or at least emulated!) if anyone can see something I might have missed? 



/**
 * Copyright (c) 2017 - 2019, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */
#include "nrfx_spim.h"
#include "app_util_platform.h"
#include "nrf_gpio.h"
#include "nrf_delay.h"
#include "boards.h"
#include "app_error.h"
#include <string.h>
#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

#define NRFX_SPIM_SCK_PIN  18
#define NRFX_SPIM_MOSI_PIN 14
#define NRFX_SPIM_MISO_PIN 17
#define NRFX_SPIM_SS_PIN   12
//#define NRFX_SPIM_DCX_PIN  30

#define SPI_INSTANCE  0                                           /**< SPI instance index. */
static const nrfx_spim_t spi = NRFX_SPIM_INSTANCE(SPI_INSTANCE);  /**< SPI instance. */

static volatile bool spi_xfer_done;  /**< Flag used to indicate that SPI instance completed the transfer. */

#define TEST_STRING "Nordic123456789012345678901234567890"
static uint8_t       m_tx_buf[] = TEST_STRING;           /**< TX buffer. */
static uint8_t       m_rx_buf[sizeof(TEST_STRING) + 1];  /**< RX buffer. */
static const uint8_t m_length = sizeof(m_tx_buf);        /**< Transfer length. */

void spim_event_handler(nrfx_spim_evt_t const * p_event,
                       void *                  p_context)
{
    spi_xfer_done = true;
    NRF_LOG_INFO("Transfer completed.");
    if (m_rx_buf[0] != 0)
    {
        NRF_LOG_INFO(" Received:");
        NRF_LOG_HEXDUMP_INFO(m_rx_buf, strlen((const char *)m_rx_buf));
    }
}

int main(void)
{
    bsp_board_init(BSP_INIT_LEDS);

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    nrfx_spim_xfer_desc_t xfer_desc = NRFX_SPIM_XFER_TRX(m_tx_buf, m_length, m_rx_buf, m_length);

    nrfx_spim_config_t spi_config = NRFX_SPIM_DEFAULT_CONFIG;
    spi_config.frequency      = NRF_SPIM_FREQ_1M;
    spi_config.ss_pin         = NRFX_SPIM_SS_PIN;
    spi_config.miso_pin       = NRFX_SPIM_MISO_PIN;
    spi_config.mosi_pin       = NRFX_SPIM_MOSI_PIN;
    spi_config.sck_pin        = NRFX_SPIM_SCK_PIN;
    //spi_config.dcx_pin        = NRFX_SPIM_DCX_PIN;
    //spi_config.use_hw_ss      = true;
    spi_config.ss_active_high = false;
    APP_ERROR_CHECK(nrfx_spim_init(&spi, &spi_config, spim_event_handler, NULL));

    NRF_LOG_INFO("NRFX SPIM example started.");

    while (1)
    {
        // Reset rx buffer and transfer done flag
        memset(m_rx_buf, 0, m_length);
        spi_xfer_done = false;

        //APP_ERROR_CHECK(nrfx_spim_xfer_dcx(&spi, &xfer_desc, 0, 15));
        APP_ERROR_CHECK(nrfx_spim_xfer(&spi, &xfer_desc, 0));

        while (!spi_xfer_done)
        {
            __WFE();
        }

        NRF_LOG_FLUSH();

        bsp_board_led_invert(BSP_BOARD_LED_0);
        nrf_delay_ms(200);
    }
}
pca10056e.zip


Parents
  • Hi,

    I tested porting the nrfx_spim example to pca10056e and I did not face any BSP related errors, however, I used a different approach than you did. I copied the pca10056e projects from uart example into nrfx_spim example, copied sdk_config from pca10056 directory into pca10056e directory, and added the missing source files required by the nrfx_spim example. I also face the multiple UART handler error, but this can easily be fixed by setting NRFX_PRS_BOX_2_ENABLED to 1 in your sdk_config.h file (fewer peripheral instances on nRF52811 cause less required resource sharing boxes, in nRF52811 box 2 is used for UART/UARTE, while box 4 is used in nRF52840).

    Attached project: nrfx_spim_pca10056e.zip

    Best regards,
    Jørgen

Reply
  • Hi,

    I tested porting the nrfx_spim example to pca10056e and I did not face any BSP related errors, however, I used a different approach than you did. I copied the pca10056e projects from uart example into nrfx_spim example, copied sdk_config from pca10056 directory into pca10056e directory, and added the missing source files required by the nrfx_spim example. I also face the multiple UART handler error, but this can easily be fixed by setting NRFX_PRS_BOX_2_ENABLED to 1 in your sdk_config.h file (fewer peripheral instances on nRF52811 cause less required resource sharing boxes, in nRF52811 box 2 is used for UART/UARTE, while box 4 is used in nRF52840).

    Attached project: nrfx_spim_pca10056e.zip

    Best regards,
    Jørgen

Children
  • thanks for the answer..

    When I get some time, I'd like to dig into what the difference is between the config for a uart project and the blinky project for the same target, I'm sure it'll be instructive to see what difference makes some defines for the bsp button handling code fall over in a screaming heap.

    I had a quick search, but haven't been able to find much info on what these PRS_BOX values even mean? letalone why I need to set one of these for a particular chip but can't for another. the SDK help files for the whole PRS are particularly frustrating in describing each setting as...  itself..... 

    Anyway - since asking this question, I decided that the 52811 isn't for this project.

    Having no room to compile a debug version of the firmware, before I had even started any dev beyond configuring some on chip peripherals and the BLE radio from a sample skeleton project that does nothing....... well, that seems to be asking for trouble. 

    I've got an nRF52-DK and some eval boards for the parts the custom board was using, and now I'm progressing on the 52832...  

  • I agree that the PRS module is not very well documented. You can see which box is used for sharing witch peripheral, for each chip, in the nrfx_prs.h header file.

Related