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

Error code 3 passed to TWI manager callback

Hi,

I'm trying to connect an NRF52840-DK to a MAX30101 Wing board via I2C/TWI. I've set up the TWI Manager to send a message asking the MAX board for its part ID.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
static uint8_t buffer[BUFFER_SIZE];
ret_code_t read_part_id(nrf_twi_mngr_t const * twi_mngr){
// Read part ID
// Read register 0xFF
ret_code_t error;
//static uint8_t buffer[BUFFER_SIZE];
static nrf_twi_mngr_transfer_t const transfers[] =
{
NRF_TWI_MNGR_READ(MAX_ADDR_READ, &buffer[0], 1, 0)
};
static nrf_twi_mngr_transaction_t transaction =
{
.callback = validate_part_id,
.p_user_data = &buffer[0],
.p_transfers = transfers,
.number_of_transfers = sizeof(transfers) / sizeof(transfers[0]),
.p_required_twi_cfg = NULL
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This is the output of the callback function:

Fullscreen
1
2
3
4
Transaction failed
0x20001540
0
read_max10_registers_cb - error: 3
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I've had a look and error code 3 is a generic internal error. Does anyone know how to fix this?

PS, I'm developing Segger EM on a Ubuntu Linux computer with SDK version 17.0.2

Parents
  • Have you confirmed that the MAX30101 is actually ACKing its address ?

    Can you step into the code to see where that error code gets generated ?

    Do you have an oscilloscope or  analyser to see what's happening on the wires ?

Reply
  • Have you confirmed that the MAX30101 is actually ACKing its address ?

    Can you step into the code to see where that error code gets generated ?

    Do you have an oscilloscope or  analyser to see what's happening on the wires ?

Children
  • Hi thanks for getting back.

    How would i best check whether its ACKing, I don't have an oscilloscope so can't monitor the wires directly.

    The error code is generated by twi_event_handler because "p_event->type != NRF_DRV_TWI_EVT_DONE".

  • George Sykes said:
    I don't have an oscilloscope so can't monitor the wires directly.

    You really should get a scope of some form.


    Anyways, you can start by printing the content of the rx buffer instead of it's pointer address.

  • Ah yes sorry for the silly mistake code is now updated. The fact that nothing is in the buffer suggests to me that it failed to communicate at all. I will try and get access to the unis labs next week but I can't take a scope home.

  • How would i best check whether its ACKing,

    Use the I2C Scanner example.

    I don't have an oscilloscope

    Since getting the activity on the wires correct is totally fundamental to all this, an analyser or scope really is a key tool to this kind of work.

    You can buy a perfectly usable logic analyser on ebay from ~ $10