System crash investigation. Vivoactive 4

Hello!

So a situation is.

I have an application that are already approved and downloaded several times. It uses BLE. Yesterday I got a report from a user with Vivoactive 4. The application causes a system crash while trying to use BLE. And it doesn't show (IQ!) as I can see sometime, but it causes system restart.

Actually it looks like this

I tried to remove my functions one-by-one but I'm stuck on removing BleDelegate. So. If I remove the delegate or all internal logic, it stops crashing.

My Forerunner945, another Fenix5+, vivoactive3m are working without this problem. Sim works as well.

And another moment. We tried to create a file with the application name under /garmin/apps/logs, but it's always empty. ERA is empty.

And the question is: How to investigate these situations? Are there crash dumps somewhere?

Thanks.

0 jim_m_58 over 5 years ago

If you see IQ!, you should take a look at the garmin\apps\logs\ciq_log.* files or see if there's anything in your ERA reports.

if it's a full device crash, check in garmin\debug for an err_log.

0 Aleks over 5 years ago in reply to jim_m_58

Thanks. we'll look into this path when the user is available.

0 Aleks over 5 years ago in reply to jim_m_58

This is err_log.

3225 (vívoactive 4) SW ver: 530
Build Type: RELEASE
Commit:784550b42954f7fd1b124b5fe2bcf23671666a99
ESN: 3320125408
01/09/21 02:50:24
RTL
errnum: 0x034
r0: 0x2001b6b8
r1: 0x00000008
r2: 0x2001b4b0
r3: 0x80000000
r4: 0x004802d0
r5: 0x00000000
r6: 0x00000008
r7: 0x2001b4b0
r8: 0x00000001
r9: 0x34049717
r10: 0x0000000d
r11: 0x34049723
r12: 0x00000018
r13: 0x2001b4e0
r14: 0x2001b480
r15: 0x00023c3d
r16: 0x004802d0
r17: 0x800f0000
r18: 0x40000000
r19: 0x00000100
r20: 0xe000ed38
r21: 0xe000ed34
r22: 0x00000000
Stack frame PC, SP: 0x001cd187, 0x2001b3b8
Call Stack - SP at 0x2001b3b8:
	0x000f6af5
	0x001364fd
	0x00023c3d
	0x00023c3d
	0x00136b11
	0x00023b75
	0x000719cb
	0x00021ea1
	0x00071af3
	0x000223ab
	0x00021f17
	0x0002bda3
	0x001377a9
	0x000a001f
	0x000a8d99
	0x001377d1
	0x000a92e3
	0x000b313d
	0x00136c51
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
	0x00000000
Uptime: 46225417

Now I built a debug version of prg and hope there will be something interesting.

BTW. I found already a topic with this "errnum: 0x034", but with no answer. forums.garmin.com/.../spontaneous-restarts

0 jim_m_58 over 5 years ago in reply to Aleks

You may want to make a CIQ bug report, including the err_log, steps to reproduce, and source code to recreate it. The CIQ folks can work with the platform folks. The platform folks are the only ones that can understand the log, as the registers and call stack need to be decoded and the fix will likely be in the firmware or VM..

0 Aleks over 5 years ago in reply to jim_m_58

Thanks! Where I can create the report?

Added. I found https://forums.garmin.com/developer/connect-iq/i/bug-reports here it is

0 Aleks over 5 years ago

Updating info for those who can face wit a similar situation.

Step-by-step we have found the root of the reason. And the root is in the call "Ble.registerProfile()"

In profile I have a service with 7 characteristics. As soon as I remove one of the characteristics the system restart is gone!

Another interesting moment was found.

In BleDelegate I added a log string like:

function onProfileRegister(uuid, status) {
        System.println("Profile register: '" + status.toString() + "'");
        ..... 
    }

I was expecting an error may be there but I got 2 as the status. "Profile register: '2'"

According to the documentation there is NO a STATUS_xxxx value with 2.

STATUS_SUCCESS	0	3.1.0	Operation Successful
STATUS_NOT_ENOUGH_RESOURCES	1	3.1.0	Operation failed due to lack of resources
STATUS_READ_FAIL	12	3.1.0	Read Request Failed
STATUS_WRITE_FAIL	14	3.1.0	Write Request Failed

Here is the source code of the profile I register.

https://github.com/newenclave/AtomAppGN/blob/master/source/AtomFastProfile.mc Is something wrong here may be? Is there limit for the characteristics?

0 Travis.ConnectIQ over 5 years ago in reply to Aleks

It looks like STATUS_NOT_ENOUGH_RESOURCES is coming through to your application with the value 2. The internal value is not being translated properly.

There is another issue that allows the application to continue executing after this error is encountered, and I think that is the source of the system crash that you see. It should crash the application before your callback is invoked, but that is not happening.

0 Aleks over 5 years ago in reply to Travis.ConnectIQ

Thanks, Travis.

What NOT_ENOUGH_RESOURCES could be related with? I mean my app is not huge (I got mem peak about 90k) now and I wanted to add features.

0 jim_m_58 over 5 years ago in reply to Aleks

resources for bluetooth. There are some limits, such as you can have at most 3 ble profiles, and I'm thinking there are other things involving the BLE stack.

0 Aleks over 5 years ago in reply to jim_m_58

Yes, I know about 3 profiles. But I think there is something else in my app. The device, I'm writing app for, has more then 7 characteristics and it'd be really sad if I couldn't support them.

I think there is something in my app, because I tried to add several characteristics to Thingy app from example. No crash.