TWI transfert stuck

RE: TWI transfert stuck

Olfox — Tue, 09 Feb 2021 07:42:11 GMT

I agree , i understand , i already move quiet a lot from original subject, new ticket is already created , thanks a lot !

RE: TWI transfert stuck

Jared — Tue, 09 Feb 2021 07:39:11 GMT

Hi,

My understanding is that the original problem regarding the TWI has been solved. We are happy to help you with the issue regarding pairing but would prefer that you made a new ticket for it. That makes it easier for other users on this forum to follow this thread when they have a similar twi problem etc..

best regards

Jared

RE: TWI transfert stuck

Olfox — Mon, 08 Feb 2021 15:01:35 GMT

You point exactly the probleme i'm faced at the moment:

I was working on pairing because i have this strange issue:

My program is based on hrs example + dfu merging.

I was thinking that, by using pairing protection with 6 digit fixed pathkey( no other choice cause no IO), i would not be able to read/write my characteriqtics. But with nrfConnect, if you are fast enough, when bounding window pops up , and you click cancel and really fast after, you are able to click on the row to read a characteristics, the connexion is maintained and you have access to all , without been securly paired !!!

I know i can protect each caracteristic by using : BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM , what i did.

But a side effect appears: after first pairing on the phone by writing the 6 digit passkey, the same windows pops up FOR EACH characteristic you read ( only the first time) ... so it s a bit anoying because you have the feeling to have paired at connexion step , but in fact it has absolutely no impact on security.

If you click cancel you are still connected and if fast enough you can even have access to all. If you paired successfully, you will have to enter this same path key for each characteristic you have protected, what give a strange effect to the final user, he has the feeling that first pairing didn't worked.

What i need is : ask pairing after connect. If android user enter correct path kay , no more ask user to enter pathkey. If no or cancel, close connexion or retry but doesn't give access. Only paired device should have access.

But now i get this error when i want to enter the passkey on android phone:

<debug> nrf_sdh_ble: BLE event: 0x12.
<debug> nrf_sdh_ble: BLE event: 0x13.
<error> peer_manager_sm: Could not perform security procedure. smd_params_reply() or smd_link_secure() returned NRF_ERROR_INVALID_ADDR. conn_handle: 0
<error> peer_manager_handler: Unexpected fatal error occurred: error: NRF_ERROR_INVALID_ADDR
<error> peer_manager_handler: Asserting.
<error> app: ERROR 16 [NRF_ERROR_INVALID_ADDR] at C:\nordic\nRF5SDK160098a08e2\components\ble\peer_manager\peer_manager_handler.c:294

RE: TWI transfert stuck

Jared — Mon, 08 Feb 2021 14:48:16 GMT

Hi,

Ok. Just want to comment that you need to start capturing before the link is decrypted. The sniffer trace doesn't fully show the communication as the link is encrypted. You have either turn off pairing or capture a trace when they pair so that the key can be sniffed by the sniffer and so that it can decrypt the link.

regards

Jared

RE: TWI transfert stuck

Olfox — Mon, 08 Feb 2021 10:37:23 GMT

HI Jared ,

Our connexion latency is solved ( it was linked to our system).

I will open dedicated topics for other issue i have , and there is ... 😃

RE: TWI transfert stuck

Olfox — Fri, 05 Feb 2021 14:56:00 GMT

[quote userid="73165" url="~/f/nordic-q-a/71160/twi-transfert-stuck/292962#292962"]The best method would be to do a direct advertising during start up. You should also use a short scan interval, short scan window, and a short advertising interval. [/quote]

HI Jared,

Ok I see , most of the time my system sleeps. With accelerometre it wakes up and start to advertise. My settings are:

data-mode="text">#define APP_ADV_INTERVAL 100//fle debug300 /**< The advertising interval (in units of 0.625 ms. This value corresponds to 187.5 ms). */ 1000 //180 00 :180sec , 100 :1sec /**< The advertising duration (180 seconds) in units of 10 milliseconds. */ 3 /**< Application's BLE observer priority. You shouldn't need to modify this value. */ 1 /**< A tag identifying the SoftDevice BLE configuration. */ MSEC_TO_UNITS(10, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.1 seconds). */ MSEC_TO_UNITS(20, UNIT_1_25_MS) /**< Maximum acceptable connection interval (0.2 second). */ 0 /**< Slave latency. */ MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Connection supervisory timeout (4 seconds). */ APP_TIMER_TICKS(5000) /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */ APP_TIMER_TICKS(30000) /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */ 3 /**< Number of attempts before giving up the connection parameter negotiation. */ 1 /**< Perform bonding. */ 1 /**< Man In The Middle protection not required. */ 0 /**< LE Secure Connections not enabled. */ 0 /**< Keypress notifications not enabled. */ BLE_GAP_IO_CAPS_DISPLAY_ONLY /**< No I/O capabilities. */ 0 /**< Out Of Band data not available. */ 7 /**< Minimum encryption key size. */ 16 /**< Maximum encryption key size. */ 0xDEADBEEF

I have to admit i'm sure of what is doing what, that could explain the time to connect also. Do you think i can improve some of these setting to be more efficient ? What could be the impact in terme of consumption increasing?

I join you a sniffer trace :

devzone.nordicsemi.com/.../with_5F00_nrfConnect.pcapng

RE: TWI transfert stuck

Jared — Thu, 04 Feb 2021 15:06:21 GMT

Hi,

Aha, I understand. So, the data length can be changed by either the peripheral itself or by the peer. I assume that the app acts a central and would therefore have the final say regarding the connection parameters. A sniffer trace would clarify which device that asks for the change in data length. The benefit of a small MTU is that it has less chance of interference. Interference would cause you to re-transmit the whole data pack, which is not good if you have a large data pack such as 247 bytes. It's therefore typical that the data length changes accordingly to the size of the data that is sent.
If you referring to the application timer, then It won't generate any events after you have stopped it. Yes, the safest would be to stop the timer and initialize it again with new timer period, and then restart it.
Ok
The best method would be to do a direct advertising during start up. You should also use a short scan interval, short scan window, and a short advertising interval.

best regards

Jared

RE: TWI transfert stuck

Olfox — Thu, 04 Feb 2021 07:52:25 GMT

Hi Jared,

1. In the log you see that MTU is set to 247, but then, it go back to 27. It has no effect and works, but i'm surprised to see this.

2. Good if Timer will not generate interrupt once stopped. I have read it will go until the end ( but may be without generate int). In fact, i can change the timer period on the fly by writing the characteristic, even when it is running. So, to avoid changing the variable period on the fly while timer is running, my idea was to stopped the timer, update the variable, and start the timer again. Is it the good way to do or if I change the timer period variable while it is running it will just take into account the new value after interupt ?

3.Yes invalid error was linked to advertise while it is advertising, my state machine was not robust. It depends on advertising timeout setting and i didn't reach adevertising timeout that i start a new one...

4.New question: I have a lot of trouble to connect fast. It always take 2 or 3 second with nrf connect, and even worth with our custom app where it could take 6 or 7 second resulting of no connecxion and advertising timeout when i set advertising timeout to 5sec. As now i have sniffer, how can i improve this connexion time (ideally in one second max) or how can i check how is the slowest on my systeme ?

Thank you !

RE: TWI transfert stuck

Jared — Wed, 03 Feb 2021 15:59:54 GMT

Hi again,

So I've read through your recent replies but I'm not sure what to conclude. It seems that you have solved some of the issues but still have some questions you would like to get answered:

[quote user="Olfox"]

Q1:But when i'm looking the log i see this:

[/quote]

I can't see that the log is actually reporting any errors? Anything specifically about it you were wondering about?

[quote user="Olfox"]

In my characteristics, i update timer periode by first stopping, change variable, and start again. It seems to not generate interupt anymore. After using stopped timer function, isa last interupt rasied before to be totally inactive ? In that case it will be dangerous because when i stop a timer, i also switch off sensors, so if a last interupt occurs after switch off, it will not be good at all.

Concerning the TWI issue, i think it was a side effect of all this combinaison of problems and was certainly not directly linked to this. I also avod to try to communicate with this missing device by searching for it one time a initialisation step. If missing, all communication with it will not be done in all code, to avoid wasting time and getting errors. It will also never be hot plugged so no problem.

For the product with the sensors, i will try to re create issu by removing it once in communication to see if program get stucked in case of nack of adress or data because i dont like to let a while like this that coud block all the system...

[/quote]

I'm not sure if I understood this correctly. The application timer will not generate another interrupt after the timer has been stopped.

[quote user="Olfox"] concerning disconnexion, i was responsible of it with the fw. Our app set a field that toogle the product in a mode where we disconnect all connexion and advertise each minute, then sleep again. I was juste not aware that this field was set by our app at this time ... lol. How is it possible to know if we are advertising, is here a function to know it ? or if we are advertising, to relaunch an advertising sequence ( exemple, i'm advertising for already 8sec/10 after timeout, i want to restart adverting for 10sec without waiting the end of the first sequence without triggered this error that i have at the moment: [/quote]

Then you have to stop advertising, and then start it again with a new set of advertising parameters that has the new timeout. Trying to start advertising when it's already advertising will result in a INVALID STATE error.

happy to help! 🙂

best regards

Jared

RE: TWI transfert stuck

Olfox — Tue, 02 Feb 2021 23:21:51 GMT

Ok i found the issue, it came from breakpoint ... i had to clear all breakpoint. Now i can debug without generating each time the setting.page.

I also make progress. There is a link between disconnection and the fact that our app try to write more than 20bytes into our characteristic. on this we do some stroke to managae each field individually and update some variable.

So i have updated the NRF_SDH_BLE_GATT_MAX_MTU_SIZE in file sdk_config.h

And i get an error on build:

After updating the RAM start and size:

I receive all my char !

Q1:But when i'm looking the log i see this:

It works anyway...

Q2: In my characteristics, i update timer periode by first stopping, change variable, and start again. It seems to not generate interupt anymore. After using stopped timer function, isa last interupt rasied before to be totally inactive ? In that case it will be dangerous because when i stop a timer, i also switch off sensors, so if a last interupt occurs after switch off, it will not be good at all.

Q3: concerning disconnexion, i was responsible of it with the fw. Our app set a field that toogle the product in a mode where we disconnect all connexion and advertise each minute, then sleep again. I was juste not aware that this field was set by our app at this time ... lol. How is it possible to know if we are advertising, is here a function to know it ? or if we are advertising, to relaunch an advertising sequence ( exemple, i'm advertising for already 8sec/10 after timeout, i want to restart adverting for 10sec without waiting the end of the first sequence without triggered this error that i have at the moment:

Thanks a lot for your help Jared, Nordic is really the best for support , i don't regret my choice to move from NXP to you :D

RE: TWI transfert stuck

Olfox — Tue, 02 Feb 2021 18:21:23 GMT

i remeber i add to set ram and flash adress in the past , may be it has move?

here my bootloader that i flash:

here section settings of the bootloader

i'm working with nrf52833

Here when i flash my application:

I'm really not confident with dfu bootloader, setting , checked signature, CRC etc ... it is a bit a weak point that i need to work on

RE: TWI transfert stuck

Olfox — Tue, 02 Feb 2021 18:15:00 GMT

Hi Jared,

1. I have installed the ble siniffer on my 10100 dev kit (52833 but seems to work with 52832 .hex)

------------

But i'm totally stuck at the moemnt with bootloader. As i'm using dfu, i have bootloader dfu . But as it checked every time crc i decided to move on debug bootloader that normally doesn't check. But now i'm unable to debug my fw, it is programmed, but normally after that there is a breakpoint in the main entry point but here nothing happen, the programm seems to run but nothing happen i can't debug anymore...

Even when i come back on secure bootloader and generate settings, i can't start debugging my fw.

😞

-------------

For the TWI bug, in fact i realise it happen on the board where the sensor is not connected ( i have to type of board , but one software). So when error happen, it jump to adress NACK in the handler twi, but goes nowhere after that. May be should i clear an error flag or something?

------------

I will ry your proposal a soon as i'm able to debug again.

RE: TWI transfert stuck

Jared — Tue, 02 Feb 2021 09:53:47 GMT

Hi,

[quote user="Olfox"]

With our app, it seems to read the characteristic and then, make occurs a disconnection of the nrf52833.

[/quote]

So the application is probably hitting an error when you try to write to the characteristic from your own custom app. This error is probably causing sd_ble_gap_disconnect() to be called somewhere in your code resulting in the disconnect. This is somehow affecting the TWI communication.

What I would like to know about the ble communication is:

What kind of error is causing the disconnection? Set a breakpoint in the ble handler where you call sd_ble_gap_disconnect() and check what event that is causing the disconnect. Could you also take a nRF Sniffer trace while you reproduce the error? Upload the trace here.
What is the state of the application after it has disconnected? Is it stuck in the error handler? Does the application reset? Is it stuck somewhere else in your application? This can easily be verified by using a debugger.

What I would like to know about the TWI communication is:

If you reset the Nordic IC. Does the TWI slave respond again?
Could you upload a trace of the SDA and SCL line when application is stuck?
Could you print something in the beginning of the twi_handler() before the switch case and see if the handler is called at all after the disconnection.
You're missing a break; in the error handler in the NRF_DRV_TWI_EVT_DATA_NACK case.

As you may understand, I need to know a lot more of what exactly happens to find the root cause. I would appreciate it if you answered the questions above to the best of your capability.

regards
Jared

RE: TWI transfert stuck

Olfox — Mon, 01 Feb 2021 16:57:24 GMT

Hi Jared, thanks for fast reply.

There is no problem with communication with the sensor. I can connect, disconnect without having issue with communication in "normal mode".

Good point is that i can reproduce on demand the problem.

It happens always , when with our own flutter app, we read a certain characteristic.

With nrfConnect android app, it never happens by reading this same caracteristic.

With our app, it seems to read the characteristic and then, make occurs a disconnection of the nrf52833.

When we read other characteristics, no problem.

I'm surprised, first because with nrfConnect there is no problem, and then, why does it produce an effect on twi. It is stucked on this while waiting for the flag to be set by the TWI Event Handler, that in the three possible case, should set this flag to true, event if there is an error:

void twi_handler(nrf_drv_twi_evt_t const * p_event, void * p_context)
{
    switch (p_event->type)
    {
        case NRF_DRV_TWI_EVT_DONE:
            if (p_event->xfer_desc.type == NRF_DRV_TWI_XFER_RX)
            {
               m_xfer_done = true;
            }
            m_xfer_done = true;
            break;
        case NRF_DRV_TWI_EVT_DATA_NACK:
            NRF_LOG_ERROR("i2C data NACK");
            m_xfer_done = true;                 //to not be stuck, even if there is an issue
       case NRF_DRV_TWI_EVT_ADDRESS_NACK:
            NRF_LOG_ERROR("i2C adress NACK");
            m_xfer_done = true;                //false to adresse means no device connected
            m_xfer_ack_adress_ok = false;
            break;
        default:
            break;
    }
}

That's mean, when the disconnect event occurs, i'm not able to reach the TWI event anymore.

Witch register can i checked to understand the problem ? Could be a priority that avoid TWI to create an event or something like this may be ?

thank you

RE: TWI transfert stuck

Jared — Mon, 01 Feb 2021 14:05:11 GMT

Hi,

You can always use the application timer library and start a timer before the loop that sets the flag to true after a certain time has elapsed. However, I think it would be better to find the root cause of the issue. Is the application resetting when the the ble disconnects? Could it be that the I2C bus is left in a invalid state such as this?

regards

Jared