i2c+timer+work keeps getting -22 or -128 and keep crashing

Hi,

I am using i2c to get sensor data. At first the client write a value to the service. In the service on write callback it trigger's a timer, in the timer, it submit a work. In the work handler, it reads data and then notify the client.

but the notify keeps returning -22 or -128, the bluetooth is connected, and the notify data is correct.

When the client disconnect, the chip crashed and auto restarted.

How should I fix this?

Thanks,

Parents
  • Hi 

    Why do you use a timer to trigger the work item, do you need to add a delay to the sensor readout? 

    Is the notification ever successful, or will it always return an error? 

    Have you tried to debug the call to gatt_notify(..) so you can see exactly where in the code the error is returned? 
    That can usually provide more details than the error code alone. 

    Would you be able to share the code showing how the sensor is read and the notification sent? 

    Best regards
    Torbjørn

  • Thank you for your sharing. It’s great that the problem is finally fixed.

    skibidi toilet

  • no its not fixed. the problem is still there: 1st connect, can't notify, but can disconnect. 2nd and later, can notify, but disconnect crash the chip.

  • Hi 

    The development platform for the nRF52811 is the nRF52840DK, and it is recommended to get one of those so you can debug the application when needed. 

    There are board files in the SDK allowing you to build for the nRF52811 on the nRF52840DK. 

    Thanks for sharing the code. I can't spot any issues in the code you shared that would explain the problem, but the code you shared doesn't show the whole application either. For instance it doesn't show where you call the fetch_and_display(..) function, which could be relevant to the issue. 

    Would you be able to share the entire project so I can try to run it on my end and reproduce the problem? 

    I can make the case private if you don't want to share your code in a public ticket. 

    Best regards
    Torbjørn

  • Thanks. Can the code run on the 52840 DK, which doesn't have the sensor? The issue is only after the sensor data retrieve. As I have replied earlier, I have figured out the -22 issue. Now the only issue left is chip crash and auto start after the client disconnect, if we retrieved sensor data. If we don't get data, the disconnect worked fine.

    If you may please advise some possibilities so I can dig in. 

  • Hi 

    kfcube said:
    Can the code run on the 52840 DK, which doesn't have the sensor?

    Do you mean if you get a kit yourself?

    Typically you would wire up a sensor board to your DK somehow so you can run on the DK with all the functionality operational. 

    In case you send code to me I would probably have to comment out the sensor code, or replace it with some other sensor I have laying around. 

    As for your disconnect issues, are you doing anything in the disconnect callback that could explain the issue? 

    Most Bluetooth callbacks are run in interrupt context, and if you try to run any blocking function calls from an interrupt it could lead to issues. 

    In order to debug the crash you should have logging enabled, then you should see a crash report that might give some indication to the cause of the problem. 

    Best regards
    Torbjørn 

Reply
  • Hi 

    kfcube said:
    Can the code run on the 52840 DK, which doesn't have the sensor?

    Do you mean if you get a kit yourself?

    Typically you would wire up a sensor board to your DK somehow so you can run on the DK with all the functionality operational. 

    In case you send code to me I would probably have to comment out the sensor code, or replace it with some other sensor I have laying around. 

    As for your disconnect issues, are you doing anything in the disconnect callback that could explain the issue? 

    Most Bluetooth callbacks are run in interrupt context, and if you try to run any blocking function calls from an interrupt it could lead to issues. 

    In order to debug the crash you should have logging enabled, then you should see a crash report that might give some indication to the cause of the problem. 

    Best regards
    Torbjørn 

Children
Related