Communication priority

[Minseo]

Hi

I am currently developing using GPIOTE, TWI, and TIMER.

There is no problem when TWI is only working, but when interrupt (GPIOTE, TIMER simultaneously) occurs, TWI stops.

I don't know why this is happening.

Please help me.

Thank you.

[Karl Ylvisaker]

Hello,

I am currently developing using GPIOTE, TWI, and TIMER.

There is no problem when TWI is only working, but when interrupt (GPIOTE, TIMER simultaneously) occurs, TWI stops.

Could you elaborate what you mean when you say that the TWI stops?
What are you observing, and how is it different from what you had expected? Does the device suddenly reset, or does everything function as expected except for the TWI? How are you monitoring the TWI?

Please also make sure to have DEBUG defined in your preprocessor defines, like shown in the included image.

This will print a detailed error message to your logger if a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.
It would also be helpful if you could share some code of your configuration and initialization of the peripherals in question.

Looking forward to resolve this issue together!

Best regards,
Karl

[Minseo]

Hi 

Thank you for reply.

Display LCD screen using GFX (ST7735s)

Designed to recognize screen touch by touching LCD

GPIOTE recognizes touch on the screen and uses Timer to distinguish touch and slides.

Receive sensor data for 20 seconds using TWI. (Check twi data using uart.)

When receiving for 20 seconds, if you touch the screen, the LCD screen stops and data coming through TWI communication stops.

The reason why twi is used nrf_drv_twi is that the twi data continues to lose in the middle during the ble setting.

(I don't know why the loss happened, but it's solved after using nrf_drv_twi)

 

Twi_init(before)                                           twi_init(After)

Thank you.

[Karl Ylvisaker]

Minseo said:

Thank you for reply.

Minseo said:

Thank you.

No problem at all, I am happy to help!

Thank you for elaborating on your project details, that makes it easier to understand. 

Minseo said:

The reason why twi is used nrf_drv_twi is that the twi data continues to lose in the middle during the ble setting.

I still do not understand what you mean by this, could you elaborate?
How are you monitoring this, and what do you mean that the data continues to lose?
Please know that the SoftDevice takes control of the CPU to meet BLE timing-critical deadlines. In this time, the CPU has complete control of the CPU, and therefore all other processes needing the CPU has to wait for it to finish. This might be what you are seeing.

Minseo said:

(I don't know why the loss happened, but it's solved after using nrf_drv_twi)

Are you saying that the issue is resolved?
The examples using the legacy nrf_drv_twi is actually forwarding to use the newer nrfx_twi driver with easyDMA though the TWI0_USE_EASY_DMA define in sdk_config. The easyDMA feature lets the transfer continue even though the CPU is busy doing SoftDevice work, because it negates the need to have the CPU process each received byte of the transfer.

Best regards,
Karl

[Minseo]

Hi

Thank you for reply.

• The reason why twi is used nrf_drv_twi is that the twi data continues to lose in the middle during the ble setting.

This meaning was talking about the problem that the value suddenly came in as 0 while communicating with the sensor through twi.

• (I don't know why the loss happened, but it's solved after using nrf_drv_twi)

This meant that it was resolved that the sensor value suddenly went to 0.

Additionally, I found out during the test yesterday.

If I update the LCD screen in the middle of twi communication, it seems like communication stops.

I set the screen touch to GPIOTE and designed the code to update the lcd screen when an interrupt occurs.

During the test, twi communication does not stop if the LCD screen is not updated when interrpt occurs.

But I checked that if I update the LCD screen when interrupt occurs, twi communication will be lost.

I haven't found a solution to this yet.

Help me.

Thank you.

[Karl Ylvisaker]

Minseo said:

This meaning was talking about the problem that the value suddenly came in as 0 while communicating with the sensor through twi.

You have never mentioned for me that you had an issue where the sensor reading suddenly became 0. Do you mean to say that you receive a successful transfer, and that transfer contains the byte with value 0? Or do you mean to say that the transfer was aborted or stopped, and when checked the buffer contained 0?

Minseo said:

This meant that it was resolved that the sensor value suddenly went to 0.

I am glad that this issue is resolved at least. 

Minseo said:

Additionally, I found out during the test yesterday.

If I update the LCD screen in the middle of twi communication, it seems like communication stops.

I set the screen touch to GPIOTE and designed the code to update the lcd screen when an interrupt occurs.

During the test, twi communication does not stop if the LCD screen is not updated when interrpt occurs.

But I checked that if I update the LCD screen when interrupt occurs, twi communication will be lost.

I haven't found a solution to this yet.

What IRQ priorities are you using for the different interrupts?
I see from your earlier screenshot that twi is using the highest app priority.
Have you made any changes to this, and/or is the highest app priority the default value?
Since the twi already has the highest app priority level, it should not be possible for it to be interrupted by the LCD update. Are you using BLE at the same time?

Is there an non-NRF_SUCCSS error returned anywhere, when the twi communication is 'lost'?
Bear in mind that I do not completely understand what you mean when you say that the twi communication is lost; does it just stop mid transfer(how have you checked this?)? Do you not receive an expected transfer? How is it behaving, and how does it differ from your expectations?
The more accurate the information you give, the easier it will be for us to resolve this.

Best regards,
Karl