Chip freezes in normal operation, but no problem when debugging

RE: Chip freezes in normal operation, but no problem when debugging

MartinBL — Tue, 23 Jan 2018 10:13:18 GMT

Great! Let us hope that was the end of it.

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Tue, 23 Jan 2018 10:04:13 GMT

Martin, thanks. I tried your method and looked like it worked. Will keep you posted.

RE: Chip freezes in normal operation, but no problem when debugging

MartinBL — Mon, 22 Jan 2018 16:05:21 GMT

You can try that or you can use the system_nrf52.c file in SDK 12.3 that has implemented the workaround in SystemInit().

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Mon, 22 Jan 2018 09:09:11 GMT

Yes, I am using SDK 11 with 52832 QFAAB0. How can I use the workaround method?

Just add *(volatile uint32_t )0x40000EE4 = ((volatile uint32_t *)0x10000258 & 0x0000004F); in the first line of main()?

RE: Chip freezes in normal operation, but no problem when debugging

MartinBL — Mon, 22 Jan 2018 08:37:28 GMT

Hi, What SDK are you using? 11? Could it be errata 108: infocenter.nordicsemi.com/.../anomaly_832_108.html

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Sat, 20 Jan 2018 01:58:21 GMT

Hi Martin, I was wrong, the answer above didn't solve the problem. It temporarily eased the problem. But after I modified my code slightly in other totally unrelated place, this freezing issue shown up again....This time, I observed one board still has the problem. Will keep an eye on how other boards runs in long term.

RE: Chip freezes in normal operation, but no problem when debugging

MartinBL — Fri, 19 Jan 2018 07:27:48 GMT

Great! Glad you figured it out.

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Thu, 18 Jan 2018 14:12:54 GMT

Martin, I think I just found a potential cause to the issue. Changing SCHED_MAX_EVENT_DATA_SIZE from sizeof(uint32_t) to sizeof(app_timer_event_t) seems to solve the problem.

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Thu, 18 Jan 2018 12:47:20 GMT

One of the biggest questions in I head is that, why the same code has different results on same type of chips? Since each chip could be made slightly differently by various production conditions, can those factors cause performance difference therefore some just have enough performance to successfully run the code while others don’t? But still doesn’t make a lot sense if they runs fine during debugging.

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Thu, 18 Jan 2018 12:43:25 GMT

For issue 2: It happens in a scheduler function.

Method 1: By setting and clearing LED1, LED2, LED3 …… on different location of the function, I know where the chip freezes base on which LEDs are set and which LEDs are cleared.

Method 2: using SEGGER_RTT_WriteString() to print out tracing data. First, physically connecting to J-link (VCC, GND, SWDIO, SWCLK) but without software connection from IAR or J-Link RTT Viewer. After the board freezes, go to J-link RTT Viewer ->File -> conncet, such that the J-link can read the last SEGGER_RTT_WriteString() printed data from chip ram buffer. Both methods verify that the chip freezes in random location of the scheduler function. The freezes location is so random that it sometimes freezes when exciting nrf_delay_ms().

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Thu, 18 Jan 2018 12:43:02 GMT

4, I verify the device freezing location in several ways: If it freezes, it would not advertise any more. The boards have multiple LEDs, I inserts nrf_gpio_pin_toggle(LEDs) in timer and other locations. If they stop blinking, I know the board is freezing.

How to know freezing location: For issue 1: I use oscilloscope to measure the current changes. I can see when the board is sleeping and when the board is waking up from sleep by a timer. I will see the current stays around 2.68 mA if the chip freezes, and it always happens at the end of timer events, in random moment (I can see the current start to drop a little at the end of the timer, then stop dropping and fluctuating around 2.68 mA).

RE: Chip freezes in normal operation, but no problem when debugging

floatcloud — Thu, 18 Jan 2018 12:41:17 GMT

Hi Martin, Regarding your questions:

1, Yes, always the same boards failed. If a board didn’t fail in the beginning, it wouldn’t failed at all.

2, I have 5 boards, 3 of them has issue1, 2 out of the 3 has issue2. Since this is not a large sample group, is it possible to be a coincidence that some of the chips are partially damaged?

3, In normal operations, I tired connecting the boards with only power supply (Vcc, GND), or physically connecting to J-link (VCC, GND, SWDIO, SWCLK) but without software connection from IAR or J-Link RTT Viewer. Both of them yielded the same result. Once I connected the board from IAR or J-Link RTT Viewer, the issues would disappear.

RE: Chip freezes in normal operation, but no problem when debugging

MartinBL — Thu, 18 Jan 2018 11:29:56 GMT

I suppose the fact that it works on some, but not all boards must be a clue.

Is it always the same boards that fail? I.e. those who work, always work. It is not just a matter of time before they too fail?
What is the failure rate?
How do you power your devices in the different scenarios?
How do you know that your device freezes when not having a debugger connected? More importantly maybe, how do you know where it freezes? Is it possible that your device has asserted and is just stuck in an endless while loop in an error handler somewhere?