Ticket Created
over 5 years ago

JAZZ-2917

Edge device crash on BLE

Hallo, 

I've been working on a companion app for a BLE device and I have been experiencing a number of issues with device crashes, so the device restarting, not the standard CIQ error.

The device I am using for testing is an Edge 530. The issues happen both when the app is sideloaded as an app or a widget, but never occur in the simulator (not sure if you can even have that crash).

These issues mainly occur when leaving the app/widget shortly after having initiated pairing (device = Ble.pairDevice(result)), and happens both if the connection has been made and if not (onConnectedStateChanged( device, state ) triggered), but can also occur when changing quickly between the scanning and device views.

This also happens when using the Thingy 52 app, with some minor changes to run on the Edge 530 (exchanging the bitmaps with smaller ones) and changing the UUIDs to something that will find our devices.

So my question is first of all, are there known issues with the BLE that can cause device crashes (specifically on the Edge 530), and is there any way to debug this sort of error?

All the best, Jonas 

Former Member
Former Member
  • Former Member
    Former Member over 5 years ago in reply to jim_m_58

    So I cleared the err_log.txt before triggering it again, below are the results:

    [
{
"unit_id":"3304335715",
"product_name":"Edge 530",
"software_part_number":"006-B3121-00",
"ms_since_epoch":1584102645000,
"system_version":"5.34",
"build_type":"PRODUCTION",
"backtrace":"
Function Address: 0x60187A3C
   Call Address at Function: 0x60187A84

Function Address: 0x6029F548
   Call Address at Function: 0x6029F61A

Function Address: 0x6029F6F8
   Call Address at Function: 0x6029F706

Function Address: 0x601863E4
   Call Address at Function: 0x60186428

Function Address: 0x60186998
   Call Address at Function: 0x60186A24

Function Address: 0x6029F548
   Call Address at Function: 0x6029F61A

Function Address: 0x6029F6F8
   Call Address at Function: 0x6029F706

Function Address: 0x60186BBC
   Call Address at Function: 0x60186C06

Function Address: 0x60185038
   Call Address at Function: 0x60185266

Function Address: 0x60185A30
   Call Address at Function: 0x60185A92

Function Address: 0x60182CF0
   Call Address at Function: 0x60182D04

Function Address: 0x6044E1E8
   Call Address at Function: 0x6044E2CA

Function Address: 0x60762CF0
   Call Address at Function: 0x60762D10

",
"error_cause":"RTL Trap",
"proprietary_info":{
    "Commit ID":"6da9b741a485ad69a16dc5540d8aa6d582b74bde",
    "Time":"2020-3-13 13:30:45",
    "Ram Dump":"2",
    "ESht PC":"0x6030715D",
    "ESht SP":"0x621E2798",
    "Project Specific":"0x621E2798",
    "CDP_LOG":"605F08A1,6045AA15,6045B811,6045AA15,605D76A5,60211D59,601CCA2D,605D23F9,601CCA2D,601CCA2D,601CCA2D,60211D59,605D76A5,",
    "RTL Error Number":"6E5D8024",
    "Error Message":"00000006,00000000,0000000C,00000000,00000000,61E91CB0,00000006,00000060,60A2F3A0,00000000,62259A7C,00000002,D04C78CC,62259A08,601862D5,60187A84,000F003F",
    "Task Name":"wscm_ble_main",
    "Saved SP":"62259A08",
    "Saved LR":"601862D5",
    "Saved PC":"60187A84",
    "R[0]":"00000006",
    "R[1]":"00000000",
    "R[2]":"0000000C",
    "R[3]":"00000000",
    "R[4]":"00000000",
    "R[5]":"61E91CB0",
    "R[6]":"00000006",
    "R[7]":"00000060",
    "R[8]":"60A2F3A0",
    "R[9]":"00000000",
    "R[10]":"62259A7C",
    "R[11]":"00000002",
    "R[12]":"D04C78CC",
    "R[13]":"62259A08",
    "R[14]":"601862D5",
    "R[15]":"60187A84",
    "cpsr":"000F003F"
    }

}
]

    Now hopefully this can provide the correct people with some context.

    Thanks for the input Thumbsup

  • over 5 years ago in reply to Former Member

    You can just post the err_log here you may have to zip it) or maybe just "insert/code"

  • Former Member
    Former Member over 5 years ago in reply to jim_m_58

    This seems pretty consistent on the edge for me at least:

    So that is running a modified Nordic thingy app, I also did a version based on your Pi project with similar behaviour. It's especially bad with it running as a widget that automatically starts scanning, then the widget loop crashes easily.

    I will have a go to see if I can extract some debug info and get to Garmin, not sure which channels to go through for that though.

    This behaviour isn't a showstopper, but definitely not something that we would want to roll out for anyone.

  • over 5 years ago

    I've seen a crash a few times if after starting to pair, I exit a widget before it's connected, but haven't found a consistent way to reproduce it.  One thing you might want to do is grab the err_log after a crash (I think user /garmin/debug on the edge) and pass that on to garmin