ATT MTU > 20 and DLE enabled - central write issue

[Jim Dattolo]

SDK12 and SD 132 v3.

I have my code working for HVX from the peripheral. I can HVX send up to 80 bytes on one characteristic in one call (ATT MTU was set to 83 and DLE negotiated for 83 as well [also tried 87]) and I see it arrive on the central no problem. When I do a write without response, on the central, of anything greater than 20 I get a successful return code from the write API and then nothing. The peripheral never gets an event for the write. Is there something that I am missing here? I followed the setup from the DLE.zip file that was posted in another thread and I do see the MTU and the DLE events come back so I know that the negotiation finished before I sent anything.

[Petter Myhre]

Strange. Do you get the BLE_EVT_TX_COMPLETE event?

You do not get any BLE_GATTS_EVT_WRITE event on the server/peripheral?

Have you done a sniffer trace to see what is happening on air?

[Jim Dattolo]

I don't see any EVT_WRITE events. I need to instrument the TX_COMPLETE event. I used to use it but there was an issue at one point where I didn't get one as expected and my state machine locked. I just moved to a main loop queue pumper to keep the TX buffers always full if there were BLE writes to process. I was going to start on the sniffer but it's a pain due to the encryption as I need to make special builds with known keys (I'm using LESC) I figured I would ask to make sure that there wasn't some known issue on SD V3 and SDK12

[Petter Myhre]

Maybe you can do a sniff without doing encryption? If the issue is still there without encryption that is.

[Jim Dattolo]

the problem is that the product has multiple layers of security and app level authentication that gets in the way of debug. The problem actually fixed it self. A file must not have recompiled when I made a change in the Eclipse project. After cleaning everything and rebuilding on one of the steps things just magically fixed themselves. It was too weird only working in one direction like that to not be an evironment problem. Tests are running well now against the code so the transport is solid with the long MTU. - Thanks!

[Jim Dattolo]

so it was user error as one of the obj files wasn't rebuilding and that caused the issue. Cleaning the project set things back running!