TWI transaction failed

RE: TWI transaction failed

Karl Ylvisaker — Mon, 09 Nov 2020 14:33:25 GMT

Hello Polimarte!

Sorry for my late reply - I have been out of office for some days.

[quote user="polimarte "]i finally i make it work![/quote]

Great, that is fantastic news! I am glad to hear that you figured it out and were able to resolve your issues!
I hope my comments and suggestions have been helpful to you in this endeavor.

[quote user="polimarte "]Thanks karl for the support! [/quote]

No problem at all, Polimarte, I am happy to help! :)

Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl

RE: TWI transaction failed

polimarte — Mon, 09 Nov 2020 14:05:58 GMT

Hi, i finally i make it work! i had some problems with SDA/SCL pins, now the first read is done correctly.

Thanks karl for the support!

polimarte

RE: TWI transaction failed

polimarte — Wed, 04 Nov 2020 16:47:01 GMT

Hi Karl i really appreciate your help!

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]This means that it will be called twice with the error_code returned by twim_xfer.[/quote]

Thanks for the note i will call the APP_ERROR_CHECK only ones in this case. II had inserted the second one as a break in case of timeout only, but you are right is not useful implemented like that.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]It seems you are only getting this NACK on the READ command, following the first Write, is this correct?[/quote]

No, unfortunately i have problem since the first read. To work with my sensor hub i have to enter in Application Mode first, through a sequence of set/clear of two pins, the Reset and the Mfio pin. This is working, even if i could not check with a logic analyzer i have seen the behave of the pins with the help of two leds. I know it is very naive. As well the sda and scl are set high, but nothing happen than. After this sequence i have the first read to apply in order to check the device mode.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]If so, what is your OXI_ADDRESS_R - where did you find it, and what does the documentation say about this address?[/quote][quote userid="92644" url="~/f/nordic-q-a/67577/twi-transaction-failed/277191#277191"] "The MAX32664 uses 0xAA as the I2C 8-bit slave write address and 0xAB is used as the I2C 8-bit slave read address"[/quote]

Initially i wrongly used two different slave adresses for the TX and RX transactions (OXI_ADDRESS_W=0xAA and OXI_ADRESS_R=0xAB) only than i noticed that the the nrfx_twim_*x nedeed the 7-bit address (LSB). So now i am using as address field 0x55 for both the transactions.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]You will indeed need the twim_tx_done set, after a STOP condition is sent. As I understand it from your provided documentation screenshot, you need the CMD_DELAY to happen AFTER the stop condition is sent, and the twim_tx_done is set.[/quote]

Thanks for this important specification about stop condition and non-blocking mode, i was a bit confused about that.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]As I understand it from your provided documentation screenshot, you need the CMD_DELAY to happen AFTER the stop condition is sent, and the twim_tx_done is set. [/quote]

I had already tryed to insert some delay between the transactions in my previous modification of the code but still i had the NACK error. I will reintroduce this dalay between TX and the RX, in the code that i have shared i have inserted a delay after the first xfer, i will change position of that.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]So, can you tell me, how long does the datasheet specify that the CMD_DELAY needs to be, and how long is your actual wait between the completion of the TX and the start of the RX, with your current code?[/quote]

The datasheet states that "The master waits for a period of CMD_DELAY (2ms) for the device to have its data ready". I have put a longer delay (6ms) as it is in my version of the code for ARDUINO (that is working correctly). i don't think it is an issue.

I checked with the twi_scanner example the address. When i directly connect the sensor to the DK it finds the right address at 0x55. I tryed than to use my read/write byte functions and they complete the transactions (the twi_*x_done is set correctly). While connecting the sensor to nRF52832 i am able to check the correct address but i am still stack at our NACK error. I am using general digital pins 16 and 17 on the nrf52832 as SDA and SCL and i am sure to have defined correctly these pins in the twi_init function as well to have connected in the right way the DK to my nrf52832.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/278396#278396"]Looking forward to getting to the bottom of this![/quote]

Thanks again Karl!

polimarte

RE: TWI transaction failed

Karl Ylvisaker — Wed, 04 Nov 2020 09:56:10 GMT

Hello Polimarte,

[quote user="polimarte "]Yes you are right, i forgot the possibility of faulty interaction of the interrupts with timer variables.[/quote]

I would not call it a faulty interaction, but yes, this is definitely something to consider. If accuracy is needed, a timer should be used instead.

[quote user="polimarte "]I have modified my code in order to retransmit at the arrival of the twim_tx_failed (NACK event) or at the timeout of the timer.[/quote]

Great! Now it accounts for the possibility of a NACK atleast. I will note that APP_ERROR_CHECK() following your waiting while loop will be called regardless of the while loop ending due to a timeout or success. This means that it will be called twice with the error_code returned by twim_xfer. This might seem insignificant now, but it could induce some trouble if you later change your error handling.

[quote user="polimarte "]In this way till flag_retry is set the transaction starts again or abort in case of timeout with APP_ERROR_CHECK. I add also a delay after the transaction but still i am stack with NACK.[/quote]

So, we will still need to resolve why the NACK is sent. Why the slave device is not responding to the second call.
Most likely ( if it is not a timing issue ), retransmission will not solve the issue in this case. You will for example get a NACK on the address if the address is not exposed on the device. Retrying the same address will then always generate NACK, since it will never be acknowledged.

It seems you are only getting this NACK on the READ command, following the first Write, is this correct? If so, what is your OXI_ADDRESS_R - where did you find it, and what does the documentation say about this address?

[quote user="polimarte "]Maybe i am missing something but i have set no flags on NRFX_TWIM_XFER_TX, allowing so the STOP condition. nrfx_twim_xfer without NRFX_TWIM_FLAG_TX_NO_STOP is blocking, suitable with the waiting for the twim_tx_done to be set, correct? [/quote]

No, this is incorrect. nrfx_twim_xfer is non blocking, even with the NO_STOP flag - this flag only means that no stop condition is generated between successive transfers. In your case, you will need a STOP condition when you switch between a read and a write command, and visa versa.

[quote user="polimarte "]I have read this, i have considered the CMD_DELAY between TX and RX solved by the possibility to have a check on the transaction state, having twim_tx_done set and the STOP condition.[/quote]

Sorry, I do not understand what you mean by this. You will indeed need the twim_tx_done set, after a STOP condition is sent. As I understand it from your provided documentation screenshot, you need the CMD_DELAY to happen AFTER the stop condition is sent, and the twim_tx_done is set. The CMD_DELAY is meant to give the slave time to prepare data / process the command, before the master may send a new command.
So, can you tell me, how long does the datasheet specify that the CMD_DELAY needs to be, and how long is your actual wait between the completion of the TX and the start of the RX, with your current code?

[quote user="polimarte "]I tryied also to insert some delay after any twim_xfer, to give time to the transaction to be done.[/quote]

I see that you have put a 6 ms delay here. What is the required CMD_DELAY as specified in the datasheet?

Looking forward to getting to the bottom of this!

Best regards,
Karl

RE: TWI transaction failed

polimarte — Mon, 02 Nov 2020 18:42:01 GMT

Hi Karl!

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"]While this implementation might function, you have no way to know how long this loop will take to complete - the time will vary for each call to your function. [/quote]

Yes you are right, i forgot the possibility of faulty interaction of the interrupts with timer variables.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"]Yes, and then have something else ( such as a retransmit ) happen if the NACK flag is set.[/quote]

I have modified my code in order to retransmit at the arrival of the twim_tx_failed (NACK event) or at the timeout of the timer.

void twim_handler(nrfx_twim_evt_t const * p_event, void * p_context)
{

    size_t primaryBufferSize = p_event->xfer_desc.primary_length;
    uint8_t *bytesTransferred = p_event->xfer_desc.p_primary_buf;
    size_t secondaryBufferSize = p_event->xfer_desc.secondary_length;
    uint8_t *bytesRead = p_event->xfer_desc.p_secondary_buf;

    switch (p_event->type)
    {
        case NRFX_TWIM_EVT_DONE:
    
            NRF_LOG_INFO("STATE OF BUFFERS IN EVENT HANDLER:");
            NRF_LOG_INFO("\t Size of primary buffer: %d", primaryBufferSize);
            NRF_LOG_INFO("\t Size of secondary buffer: %d", secondaryBufferSize);
          
					if (p_event->xfer_desc.type == NRFX_TWIM_XFER_TX)
            {
                twim_tx_done = true;
            }
          
					if (p_event->xfer_desc.type == NRFX_TWIM_XFER_RX)
            {
                twim_rx_done = true;
            }
            break;
        
		case NRFX_TWIM_EVT_ADDRESS_NACK:
						if (p_event->xfer_desc.type == NRFX_TWIM_XFER_TX)
            {
                twim_tx_failed = true;
            }
          
						if (p_event->xfer_desc.type == NRFX_TWIM_XFER_RX)
            {
                 twim_rx_failed = true;
            }
            NRF_LOG_INFO("Received NACK after sending address!");
            break;
        
		case NRFX_TWIM_EVT_DATA_NACK:
            NRF_LOG_INFO("Received NACK after sending data.");
            break;
        default:
            break;
    }

	}
	
uint8_t readByte( uint8_t familyByte, uint8_t indexByte)
{
    
	
		uint8_t flag_retry=1;
	
		nrfx_err_t err_code;

		uint8_t StatusByte;    
        uint8_t ReturnByte;
   
        uint8_t rx_buffer[2];
		size_t rx_lenght =2;

		uint8_t tx_buffer[] = {familyByte, indexByte};    
		size_t tx_lenght = sizeof(familyByte) + sizeof(indexByte);

		while(flag_retry==1){
		uint32_t timeout = OXI_TWI_TIMEOUT;
		nrfx_twim_xfer_desc_t tx_xfer = NRFX_TWIM_XFER_DESC_TX(OXI_ADDRESS_W, tx_buffer, tx_lenght);
		err_code = nrfx_twim_xfer(&twim_instance, &tx_xfer, 0);
		nrf_delay_ms(6);
		APP_ERROR_CHECK(err_code);
		
		while((!twim_tx_done) && --timeout && 	twim_tx_failed == false);
		if(!timeout) err_code=NRF_ERROR_TIMEOUT;
		APP_ERROR_CHECK(err_code);
		if(twim_tx_done) flag_retry=0;
		if(twim_tx_failed) flag_retry=1;
		}
		

		flag_retry=1;
		
		
		while(flag_retry==1){
		uint32_t timeout = OXI_TWI_TIMEOUT;
			
		nrfx_twim_xfer_desc_t rx_xfer = NRFX_TWIM_XFER_DESC_TX(OXI_ADDRESS_W, rx_buffer, rx_lenght);
		err_code = nrfx_twim_xfer(&twim_instance, &rx_xfer, 0);
		APP_ERROR_CHECK(err_code);
		
		while((!twim_rx_done) && --timeout && 	twim_rx_failed == false);
		if(!timeout) err_code=NRF_ERROR_TIMEOUT;
		APP_ERROR_CHECK(err_code);
		if(twim_rx_done) flag_retry=0;
		if(twim_tx_failed) flag_retry=1;
		}
		
		StatusByte = rx_buffer[0];
        NRF_LOG_INFO("Status Byte: %lu \n",StatusByte);
    
		ReturnByte = rx_buffer[1];  
		return ReturnByte;
}

In this way till flag_retry is set the transaction starts again or abort in case of timeout with APP_ERROR_CHECK. I add also a delay after the transaction but still i am stack with NACK.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"]This is correct, and with the current implementation this is as expected - since the nrfx_xfer function is non-blocking, it will return before the slave device has had the chance to NACK ( or otherwise misbehave ). [/quote]

Maybe i am missing something but i have set no flags on NRFX_TWIM_XFER_TX, allowing so the STOP condition. nrfx_twim_xfer without NRFX_TWIM_FLAG_TX_NO_STOP is blocking, suitable with the waiting for the twim_tx_done to be set, correct?

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"] Apart from the screenshot you should see a debug output if anything else than NRF_SUCCESS was returned. [/quote]

I have the RTT viewer which display the NACK and the TWIM viewer where the TX starts and the AMOUNT of bytes transferred is always 0. Where i can catch and show you other useful debug outputs?

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"]I did a quick search for the part number MAX32664 and found this datasheet. Is this the part you are working with?[/quote]

Yes, i am working on it!

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"]Among other things, it describes that the device needs a given CMD_DELAY to ready data for transfer - this could for example lead the device to NACK a request, since it is not yet ready to proceed with a transfer. [/quote]

I have read this, i have considered the CMD_DELAY between TX and RX solved by the possibility to have a check on the transaction state, having twim_tx_done set and the STOP condition.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277404#277404"]it describes that the device needs a given CMD_DELAY to ready data for transfer - this could for example lead the device to NACK a request, since it is not yet ready to proceed with a transfer. [/quote]

I tryied also to insert some delay after any twim_xfer, to give time to the transaction to be done.

Thanks,

polimarte

RE: TWI transaction failed

Karl Ylvisaker — Wed, 28 Oct 2020 13:38:11 GMT

[quote user="polimarte "]I have modified my code with a timer in this way, introducing a timeout: [/quote]

While this implementation might function, you have no way to know how long this loop will take to complete - the time will vary for each call to your function. This is due to the fact that your readByte function might be interrupted during this loop - which would make the "timeout" rundown take longer.
Additionally, since WFE is being used in the timeout loop, you will not necessarily know (unless you have a periodic event happening) how long this will take. Imagine a sequence in which there is a 1 minute gap in between events - during this minute, the timeout variable will not change at all, since the device will be waiting for an event to occur.

[quote user="polimarte "]What do you mean with something else? What you suggest me is to use a flag in case of NACK and restart the transition, is it correct? [/quote]

Yes, and then have something else ( such as a retransmit ) happen if the NACK flag is set. So, the function waits for either twi_*x_done to be set, and then proceed with the function, or for another flag twi_*x_failed to be set, in which case it aborts the remaining part of the "readByte" function, and either tries again, or resolves the NACK issue in some other way.

[quote user="polimarte "]This is a thing that really i don't understand, as you can see from the screenshot of the Debugger i don't receive any err_code. It gives me NRF_SUCCESS.[/quote]

It is not so easy for me to get a good understanding of exactly what is happening from screenshots, but yes, I see that the variable is 0, indicating success. Apart from the screenshot you should see a debug output if anything else than NRF_SUCCESS was returned.

[quote user="polimarte "]So without the loop waiting for the NRFX_TWIM_EVT_DONE my code run over the transition without stopping at the CHECK. What am i missing here? [/quote]

This is correct, and with the current implementation this is as expected - since the nrfx_xfer function is non-blocking, it will return before the slave device has had the chance to NACK ( or otherwise misbehave ). Therefore, you will have to add some kind of wait in between the two calls.
If you were to change your implementation of this, you could split the function into multiple parts, that start a timer when they conclude - and when this delay timer expires, it checks if the previous transfer was successful - and then uses the result of this check to either proceeds with the transactions, or retransmit.

[quote user="polimarte "]I don't have further expanation on the datasheet about how the handle NACK events unfortunately.[/quote]

I did a quick search for the part number MAX32664 and found this datasheet. Is this the part you are working with?
Please take a look at page 18 and 19, as they give a more detailed, plain-text, description of both a read and a write sequence.
Among other things, it describes that the device needs a given CMD_DELAY to ready data for transfer - this could for example lead the device to NACK a request, since it is not yet ready to proceed with a transfer.

Best regards,
Karl

RE: TWI transaction failed

polimarte — Tue, 27 Oct 2020 15:20:38 GMT

Hi Karl!

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277054#277054"]are you content with using the RTT viewer? [/quote]

That's fine, i will continue to work with RTT viewer.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277054#277054"]Alternatively, you could also add a timer that only lets your while-loops run for so long.[/quote]

I have modified my code with a timer in this way, introducing a timeout:

uint8_t readByte( uint8_t familyByte, uint8_t indexByte)
{
        uint32_t timeout = OXI_TWI_TIMEOUT;
		nrfx_err_t err_code;

		uint8_t StatusByte;    
        uint8_t ReturnByte;
   
        uint8_t rx_buffer[2];
		size_t rx_lenght =2;

		uint8_t tx_buffer[] = {familyByte, indexByte};    
		size_t tx_lenght = sizeof(familyByte) + sizeof(indexByte);

		nrfx_twim_xfer_desc_t tx_xfer = NRFX_TWIM_XFER_DESC_TX(OXI_ADDRESS_W, tx_buffer, tx_lenght);
		err_code = nrfx_twim_xfer(&twim_instance, &tx_xfer, 0);
		APP_ERROR_CHECK(err_code);
		
		while((!twim_tx_done) && --timeout)
        {
            __WFE();
        } 
		if(!timeout) err_code=NRF_ERROR_TIMEOUT;
		else  twim_tx_done  = false;
		APP_ERROR_CHECK(err_code);
 

		nrfx_twim_xfer_desc_t rx_xfer = NRFX_TWIM_XFER_DESC_RX(OXI_ADDRESS_R, rx_buffer, rx_lenght);
		err_code = nrfx_twim_xfer(&twim_instance, &rx_xfer, 0);
		APP_ERROR_CHECK(err_code);
	
        while((!twim_rx_done) && --timeout)
        {
            __WFE();
        } 
		if(!timeout) err_code=NRF_ERROR_TIMEOUT;
		else  twim_rx_done  = false;
		APP_ERROR_CHECK(err_code);
  
	
		StatusByte = rx_buffer[0];
        NRF_LOG_INFO("Status Byte: %lu \n",StatusByte);
    
		ReturnByte = rx_buffer[1];  
		return ReturnByte;
}

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277054#277054"]I think the easiest fix ( but not prettiest) to this problem would be to just add another variable that is set if the transaction failed, and then tries it again or does something else.[/quote]

What do you mean with something else? What you suggest me is to use a flag in case of NACK and restart the transition, is it correct?

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277054#277054"]Is your APP_ERROR_CHECK on line 16 of readByte returning any errors?[/quote]

This is a thing that really i don't understand, as you can see from the screenshot of the Debugger i don't receive any err_code. It gives me NRF_SUCCESS. So without the loop waiting for the NRFX_TWIM_EVT_DONE my code run over the transition without stopping at the CHECK. What am i missing here?

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/277054#277054"]We should also look into why the address is returning a NACK.[/quote]

As you can see here in the first lines:

it's said: "The MAX32664 uses 0xAA as the I2C 8-bit slave write address and 0xAB is used as the I2C 8-bit slave read address" and than in the following pages "The eight bits to be transferred as a slave address for the MAX32664 is 0xAA for a write transaction". So i am using different slave adresses for the TX (0xAA) and the RX(0xAB) as indicated. Am i wrong about this? I don't have further expanation on the datasheet about how the handle NACK events unfortunately.

Thanks for your help!

Polimarte

RE: TWI transaction failed

Karl Ylvisaker — Tue, 27 Oct 2020 08:59:47 GMT

Hi Polimarte,

[quote user="polimarte "]it is a pleasure to hear you again![/quote]

Likewise! It is great to see you progress with your application!

[quote user="polimarte "]I have to admit that i found some problems in enabling the log uart in the last SDK so i am using the RTT viewer but nothing happen on my RTT terminal if i am stack in a loop as in my case.[/quote]

I understand. Is this something you would like to look into also, or are you content with using the RTT viewer? RTT is just as good a backend for the logger as UART, by the way, it is just that it requires an RTT compatible terminal.

[quote user="polimarte "]

My code is stack at the loop for twim_tx_done, so NRFX_TWIM_EVT_DONE is never set.

If i comment these loop on both the Read/Write Bytes functions on my window, my code run without block and i can see this on the RTT viewer:

[/quote][quote user="polimarte "]Yes i can enter on the twim_handler and as i can see from the RTT viewer i get : NRFX_TWIM_EVT_ADDRESS_NACK.[/quote]

From your code, I would expect this behavior. Looking at your read and write function, they do not account for the possibility that you may receive an error.
In essence, if you call readByte now, it will go into the while-loops, and wait for the DONE event to let it exit the waiting. If instead an TWIM error is received, then the error event is generated, and twim_*x_done is never set. Since the transaction failed, and is not restarted, the twim_*x_done will never be set, and you will be stuck in the loop forever.

I think the easiest fix ( but not prettiest) to this problem would be to just add another variable that is set if the transaction failed, and then tries it again or does something else. Alternatively, you could also add a timer that only lets your while-loops run for so long. Is your APP_ERROR_CHECK on line 16 of readByte returning any errors?

We should also look into why the address is returning a NACK. What does the datasheet for your sensor say, what is the possible reasons for the device to NACK the address?

[quote user="polimarte "]Yes, i do. I am using KEIL. Unfortunately i m still studying how to setup the logic analyzer because i am not able to let it work properly (i am getting always "Unknown Signal").[/quote]

I see. It is a great tool to have available when working with serial protocols, since this would uncover any unexpected behavior on the lines.
I think the current problem lays in the code - which we will continue debug - but for future debugging it would be great to have the logic analyzer up and running.

[quote user="polimarte "]Mange Takk Karl![/quote]

Prego, Polimarte! :)

Best regards,
Karl

RE: TWI transaction failed

polimarte — Mon, 26 Oct 2020 15:41:14 GMT

Hi Karl, it is a pleasure to hear you again!

I have to admit that i found some problems in enabling the log uart in the last SDK so i am using the RTT viewer but nothing happen on my RTT terminal if i am stack in a loop as in my case.

My code is stack at the loop for twim_tx_done, so NRFX_TWIM_EVT_DONE is never set.

If i comment these loop on both the Read/Write Bytes functions on my window, my code run without block and i can see this on the RTT viewer:

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/276930#276930"]Are you ever entering your twim_handler?[/quote]

Yes i can enter on the twim_handler and as i can see from the RTT viewer i get : NRFX_TWIM_EVT_ADDRESS_NACK.

[quote userid="87869" url="~/f/nordic-q-a/67577/twi-transaction-failed/276930#276930"]Do you have access to a logic analyzer, so you may see what is happening on the pins themselves? [/quote]

Yes, i do. I am using KEIL. Unfortunately i m still studying how to setup the logic analyzer because i am not able to let it work properly (i am getting always "Unknown Signal").

Mange Takk Karl!

polimarte

RE: TWI transaction failed

Karl Ylvisaker — Mon, 26 Oct 2020 14:59:34 GMT

Hello Polimarte!

From your included screenshot you seem to be encountering some errors. Is this correct? Which errors are these, and where do they come from?

Are you ever entering your twim_handler?

[quote user=""]No task is started and no byte is transferred.[/quote]

Do you have access to a logic analyzer, so you may see what is happening on the pins themselves?

[quote user=""]I don't receive any error (err_code always 0 (NRF_SUCCESS)) but it seems that after the first transaction (TX) nothing happen as i can see from the TWIM0 window:[/quote][quote user=""]No task is started and no byte is transferred.[/quote]

Please elaborate where you are reading this. From what I can see in your screenshot, both ERROR and TXSTARTED is true - leading me to believe that a TX in fact is started, and an error is returned somewhere.
Let us start by finding the source of this error, so we may get to the bottom of why this is not working as expected.

Looking forward to resolving this issue together!

Best regards,
Karl