TWI hard faulting

[[email protected]]

Been working to get the TWI communicating to a LIS331HH and been having tons of trouble getting it functioning.

I do an init like the example

void twi_init (void)
{
    ret_code_t err_code;

    const nrf_drv_twi_config_t twi_config = {
       .scl                = SCL_PORT,
       .sda                = SDA_PORT,
       .frequency          = NRF_DRV_TWI_FREQ_100K,
       .interrupt_priority = APP_IRQ_PRIORITY_MID,
       .clear_bus_init     = 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);
}

then when i try to do any tx/rx

    ret_code_t err_code;
    uint8_t twidat = 0;
    err_code = nrf_drv_twi_rx(&m_twi,0x18,&twidat,sizeof(twidat));
    APP_ERROR_CHECK(err_code);

following the code by stepping in it goes to this function and hardfaults

__STATIC_INLINE void nrf_twi_int_enable(NRF_TWI_Type * p_reg,
                                        uint32_t       mask)
{
    p_reg->INTENSET = mask;
}

thanks,

Kevin

[Jørgen Holmefjord]

Hi,

How is m_twi defined in your application?

Are you triggering the TX/RX operations from main or interrupt context?

Do you use a SoftDevice in your application? 

Which SDK version are you using?

Best regards,
Jørgen

[[email protected]]

Hi Jørgen, thank you for taking the time to look into this.

1) it's defined globally at the top of one of our .h files;

which is included at the bottom of our main includes section;

2) we've tried several methods, i'm currently down to a simple example to try to get something working and hoping to built from there-this is currently called in main after are setup;

3) S112, i think we originally copied this project from the PCA10040e S112 blinky example

4) nRF5_SDK_17.1.0_ddde560

we have a git repo if that helps.

[Jørgen Holmefjord]

The hardfault seems to be caused by modifications in the file "salt_lick_firmware\modules\nrfx\mdk\nrf52810_peripherals.h". Reverting this file back to the original from nRF5 SDK v17.1.0 seems to fix the issue.

Setting TWIM_COUNT to 0 will create an empty array of m_handlers in nrf_drv_twi.c, which makes the TWI interrupt handler trying to call an invalid address. The MDK files should normally not be modified, as this can cause issues like this.

[[email protected]]

Thanks, I think that and some cleanup did the trick. I'm getting some data back but it looks bogus.

Should I be using the 7-bit slave address 0x18 or the 8 bit address 0x30?

[Jørgen Holmefjord]

You should use the 7-bit address, see that the ADDRESS register for TWIM is only 7 bits.

If there is no slave on the bus responding to the address, you should receive an address NACK error.

Note that you can also use the TWI_scanner example to detect the address of connected slave devices.

[[email protected]]

cool example. love the concept but it seems to be just incrementing and counting from 1 to 127. seems to be a similar problem to this guy;

 twi scanner showing random address 

I'm wondering if it's because we only have 10k pullups..? Is there a way to enable the internal pullups on the sda/scl lines to help this out?

Also when we start implementing this into our design, is it in your opinion better to just use the twi manager?

btw thanks again for all the help, really appreciate it Jørgen!

[Jørgen Holmefjord]

[email protected] said:

cool example. love the concept but it seems to be just incrementing and counting from 1 to 127. seems to be a similar problem to this guy;

 twi scanner showing random address 

Not sure why that would happen. Have you checked the TWI pins with a logic analyzer? Is one of the pins tied to GND/VDD?

[email protected] said:

I'm wondering if it's because we only have 10k pullups..? Is there a way to enable the internal pullups on the sda/scl lines to help this out?

The internal pull resistors should be enabled by default by the TWI driver. You should normally not need to add external pull resistors.

[email protected] said:

Also when we start implementing this into our design, is it in your opinion better to just use the twi manager?

That depends on your application, and what you will be interfacing. TWI manager is a higher-level library on top of the TWI drivers to easily allow you to change the configuration of the TWI peripheral between transfers, or to schedule more transfers to different devices. If your TWI slaves all support the same configuration, the driver will normally work fine as well.