TWI hanlder is not called

RE: TWI hanlder is not called

twihtronics — Sat, 16 Feb 2019 22:48:23 GMT

one more comment I forgot to add; nfc pins have added capacitance so the frequency at which those pins can operate at will be much lower than normal gpio. depending on your slaves capability for frequency you may not be able to operate i2c over those pins.

RE: TWI hanlder is not called

HTRRA — Thu, 14 Feb 2019 14:09:33 GMT

Thank you very much

RE: TWI hanlder is not called

twihtronics — Thu, 14 Feb 2019 13:57:55 GMT

same type of thing with all of the multi function pins like P21/Reset. You have to use a macro to allow GPIO usage.

Also please note since this is a UICR setting you will need to erase the entire chip first then program with your updated code in order for the setting to take place.

RE: TWI hanlder is not called

twihtronics — Thu, 14 Feb 2019 13:54:14 GMT

Pin 9 and 10 are also NFC1 and NFC2.

You have to disable the NFC functionality in order to use pins 9 & 10.

I have used the same pins in a similar project using the BT832F

It is a setting in UICR.

You can enable/disable with the CONFIG_NFCT_PINS_AS_GPIOS macro. If this is defined then pins 9 and 10 are used as GPIO.

RE: TWI hanlder is not called

HTRRA — Thu, 14 Feb 2019 13:41:14 GMT

my scl and sda were connected to p09 and p010. i have changed them to p07 and p08, and everything is working fine. Do you have any idea why the p09 and p010 pins are caused this error?

RE: TWI hanlder is not called

twihtronics — Tue, 12 Feb 2019 13:42:32 GMT

understood but I believe you are running async so without a flag to stop the program from accessing the bus you will most likely always get a error_busy fault. Your handler should clear the flag and application should set the flag.

reset flag

call twi_tx

while((flag) == 0); // wait it handler to clear flag

reset flag

call twi_rx

Note reset, set, clear and be whatever 0 or 1 value logic you pick.

This is why I think when you have null as the handler it works. Using null make the twi call do a busy wait while providing the handler allows the program to continue executing.

RE: TWI hanlder is not called

HTRRA — Tue, 12 Feb 2019 12:24:20 GMT

my problem is that the twi_handler function is not called after the twi call. I wanted to use Twi_Hanlder to set flags.

RE: TWI hanlder is not called

twihtronics — Mon, 11 Feb 2019 13:35:29 GMT

when you have a handler i believe you are running in async mode vs polling when no handler (null) is used. If this is correct then you would need to wait for the first command to finish before sending the second command. If not then you will be accessing the bus before the bus is clear or released. You can use m_xfer_done as a flag to resolve the issue.

RE: TWI hanlder is not called

HTRRA — Mon, 11 Feb 2019 08:19:40 GMT

#define LSM330D_WHO_AM_I_G 0x0F

bool LSM330DLC_init(uint8_t address_g, uint8_t address_a) {
  //whoami_read_gyro
  uint8_t whoami = LSM330D_WHO_AM_I_G;
  uint8_t resultsWhoAmI;

  nrf_drv_twi_tx(&m_twi, address_g, &whoami, 1, true);
  nrf_drv_twi_rx(&m_twi, address_g, &resultsWhoAmI, 1);

  if (resultsWhoAmI != LSM330D_WHOAMI_G_VAL)
    return false;

  return true;
}

When reading from the LSM without using TWI_HANDLER, " NULL" in the nrf_drv_twi_init
function:

ret_code_t ret = nrf_drv_twi_init(&m_twi, &twi_lsm330dlc_config, NULL, NULL);
if(ret != NRF_SUCCESS) SEGGER_RTT_TerminalOut(0, "ERROR");

no errors are returned. The function returns NRF_SUСCESS.

But when i use TWI_HANDLER, returns NRF_ERROR_BUSY, in second twi call


ret_code_t ret = nrf_drv_twi_init(&m_twi, &twi_lsm330dlc_config, twi_handler, NULL);
if(ret != NRF_SUCCESS) SEGGER_RTT_TerminalOut(0, "ERROR");

RE: TWI hanlder is not called

twihtronics — Mon, 11 Feb 2019 00:50:26 GMT

showing the code which makes the twi calls would be helpful. Also are you getting back any error for the call?