I2C pin assignment on ISP4520

[tyro01]

Hello,

I am referring to the ISP4520 example code.

I would like to change the I2C(TWI) pin assignments as below.

SCL:P0_07 / SDA:P0_12

But I can't find where to set the pin assignments. Where should I refer to?

Thanks,

tyro

[tyro01]

An ISP4520 example code was programmed for the Development Kit(Test  Board and Gateway). These boards had not I2C(TWI) connected sensors. It seems I need to code the I2C(TWI) functions on my own.

TWI Sensor Example

Setting Up TWI on nRF52xx

[Edvin]

Hello,

In your initial post, you refer to some I2C example (from the github page, I guess). What example from that link do you refer to? Is it inside the folder "lora"? "Lorawan"? Please give the full path.

Also, this github that you linked to is not delivered by Nordic. It is a private repository. I can have a quick look after I know what exactly you are trying to do, but for questions directly on this github repository, I suggest that you contact the author of this github, as they are probably more familiar with that code in particular.

BR,

Edvin

[tyro01]

Hi Edvin,

I want make an original ISP4520 based TWI sensor with LoRaWAN end-device. I refer to ISP4520-examples-master/src/apps/lorawan/end-device.

ISP4520 is InsightSIP product, normally, an empty project file with complete internal wireless-related settings would be easier to understand, but the only one provided is a sample application.

This sample application runs on their evaluation board. As I mentioned in my second post, the schematic for that evaluation board does not include a sensor with a TWI connection. I think it is inevitable that the TWI-related headers are not included.

Tx Test Board Mote

Therefore, it appears that I will have to implement the code regarding TWI by myself, referring to Nordic's SDK or a blog on an external site.

My understanding is that it would be a good idea to start by adding a TWI-related header file to main.c.

// nRF
#include "nrf.h"
#include "app_error.h"
#include "app_timer.h"
#include "app_scheduler.h"
#include "nrf_delay.h"
#include "nrf_drv_clock.h"
#include "nrf_pwr_mgmt.h"
#include "nrf_drv_twi.h" // Add header file for TWI communication

Then declare the port to be used for TWI.

void twi_init(void)
{
    ret_code_t err_code;

    const nrf_drv_twi_config_t twi_config = {
        .scl = 7,   // P0_07
        .sda = 12,  // P0_12
        .frequency = NRF_TWI_FREQ_100K,
        .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
        .clear_bus_init = false,
        .hold_bus_uninit = false};

    err_code = nrf_drv_twi_init(&m_twi, &twi_config, twi_handler, NULL);
    APP_ERROR_CHECK(err_code);

    nrf_drv_twi_enable(&m_twi);
}

TWI_ENABLED has to be set to set to High on sdk_config.h

// <e> TWI_ENABLED - nrf_drv_twi - TWI/TWIM peripheral driver - legacy layer
//==========================================================
#ifndef TWI_ENABLED
//#define TWI_ENABLED 0
#define TWI_ENABLED 1
#endif

Is the above procedure generally correct?

However, sdk_config.h has a similar configuration item as follows. I am concerned that it may conflict with NRFX functions.

// <e> NRFX_TWI_ENABLED - nrfx_twi - TWI peripheral driver
//==========================================================

I am new to Nordic, so I don't know what "Legacy Layer" means to them. I would also like to know why we still use legacy layer.

Regards,

tyro

[Edvin]

Hello tyro,

tyro01 said:

I am new to Nordic, so I don't know what "Legacy Layer" means to them. I would also like to know why we still use legacy layer.

Yes. It is very understandable that this is confusing. A couple of years back, we introduced a new set of peripheral drivers called "nrfx drivers". With these, we also added NRFX_... definitions in sdk_config.h, but for some reason we kept the old "legacy" definitions as well, so now there is two sets of definitions. 

If you look at the file "apply_old_configs.h" or "apply_old_config.h" (I think it is the first one, but it may be the second one), you will see how it treats the definitions if e.g. both TWI_ENABLED and NRFX_TWI_ENABLED are defined. I don't even remember (by heart) which one that will overwrite the other, so I just put them to the same value. So set both TWI_ENABLED 1 and NRFX_TWI_ENABLED 1. If you want to delete one of them, look at how the apply_old_configs.h is set up. 

The way you change the TWI pins should be perfectly fine. Does it not work? Did it work before you changed the pins?

If it doesn't work, my main concern is that on the DK, pin P0.07 is by default used by the UART, so either if your application is using the UART directly or for logging, that may be the reason why it doesn't work with pin P0.07. As for P0.12, that shouldn't be used by anything by default. 

So either try to change it to use e.g. P0.26 and P0.27 (those aren't used for anything by default, and they are close together on the (DK at least). Or try to disable the UART (logging if you are using that, or if your application is using the UART for anything else, or move the pins that are used by the UART). 

If you are stuck, let me know if the application is using UART for anything.

Best regards,

Edvin

[tyro01]

Hello Edvin,

Thank you very much for your explanation. I understood about a back ground of stack development.

Edvin said:

So set both TWI_ENABLED 1 and NRFX_TWI_ENABLED 1. If you want to delete one of them, look at how the apply_old_configs.h is set up.

Yes I will do that too. I found apply_old_config.h in SDK v16 directory.

Many microcontroller manufacturers develop their own drivers and provide them to their customers. However, there are now several different writing methods mixed in every product. Users need to understand how these were developed.

I do not believe the port used for TWI will conflict with any existing functionality, but if I find a problem I will ask here.

Best regards,

tyro01

[tyro01]

P.S.

P0.07 is used for UART RTS on board.h. Since RTS/CTS is not used this time, move to an unused port.

// External pin configuration
#define PIN_UART_RTS    7   // UART RTS for AT commands
#define PIN_UART_TX     6   // UART TX for AT commands
#define PIN_UART_CTS    5   // UART CTS for AT commands
#define PIN_UART_RX     8   // UART RX for AT commands
#define PIN_NVM_ERASE   12  // Non-volatile data erase

tyro01