This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

app_twi stuck in internal_transaction_in_progress

Hi,

I'm trying to communicate the nrf52832 with a LIS2DH accelerometer and when I'm trying to read 192 (32*6) bytes of data (to empty the entire accelerometer's FIFO) my code gets stuck on the line 367 of 'app_twi.c' file since the internal_transaction_in_progress=1.

I don't know if using EasyDMA would help... I can read and communicate with the acelerometer without problems, but when I try to read those registers I get this situation.

Also I don't know if it's better to use the app_twi_perform or the scheduled one for this situation.

Thank you!

PD: I have attached the project, is based on the BLE_uart, this way I can send commands to it... (the function is the "read_all_axis").app_uart.rar

  • The flag internal_transaction_in_progress should be cleared in the transaction callback. Have you checked if the callback handler (internal_transaction_cb) is called (by printing a log message), or checked with a logic analyzer if the transaction is happening on the TWI bus?

    If you should use app_twi_perform() or app_twi_schedule() depends en your application. Internally, app_twi_perform() use app_twi_schedule(), so the execution will be the same, except that your application will be blocked until the TWI transaction is cempleted.

  • I do other transactions before without problems (the internal_transaction_in_progress flag is cleared correctly and I can read/write to the device), but when I try to read those 196 bytes at the same time it's stuck on this bucle... This is the function I call to do the 192 byte read:

    static uint8_t	read_buffer[192];
    
        void read_all_axis(void){
    	static app_twi_transfer_t const transfers[] ={
    		LIS2_READ32_XYZ(&read_buffer[0],192)
    	};
    	uint32_t err_code=app_twi_perform(&m_app_twi, transfers, 192,NULL);
      APP_ERROR_CHECK(err_code);
    }
    
  • Did you check if there is any activity on the bus when you call this function?

  • Well I discovered part of the problem: The number of transfers isn't 192, it's 2. I do 2 transfers and the read trasfer reads 192 bytes. Now the problem I'm facing is that theorically the acelerometer changes the output register adress automatically with every burst read, but when I do the read the result is the same value 192 times... So now I don't know if the auto address doesn't work or if I need to send a combo of 'read+STOP_TWI' signal or whatever... Any hints?

  • Ok I solved it now! The problem was with the acelerometer... I need to put the MSB of the register address to '1' before starting the read process... Anyway the main problem was the confusion of the '192' transfers. Thank you!

Related