NRF52832 in Hard Fault State.

RE: NRF52832 in Hard Fault State.

MartinBL — Tue, 23 Jan 2018 08:59:37 GMT

Sounds like a faulty IC then. There could be several reasons:

Unfortunately, on rare occasions it happens that faulty ICs slip through the testing at the fabrication houses and reach our customers.
The chip has been damaged by ESD.
The chip has been damaged by over voltage.
I suppose it could also be caused by bad soldering.

If you find more faulty ICs, please open a support case in our official support portal,MyPage, and we will investigate further.

RE: NRF52832 in Hard Fault State.

soumil — Tue, 23 Jan 2018 05:24:17 GMT

Hey Martin. We got the Nordic chip replaced today and the hard fault error is gone. The code is working fine as usual. We are still not sure what happened. Also, we measured the voltage at DEC1 and now it is coming out to be 1.1V instead of the previous 750mV. Could that be a reason?

RE: NRF52832 in Hard Fault State.

soumil — Tue, 23 Jan 2018 04:58:03 GMT

Yes Martin. We were running the same code in the Development Board for the past few months and it has been running smoothly. Even in this custom board, it ran fine for a couple of days only after which it gave a hard fault. It is because of this reason I have been saying that it is an hardware issue rather than FW.

RE: NRF52832 in Hard Fault State.

MartinBL — Mon, 22 Jan 2018 15:04:46 GMT

Have you tried the exact same hex file on a development board? If that works it points towards a HW issue. If it doesn't work it is probably related to FW.

RE: NRF52832 in Hard Fault State.

RK — Sun, 21 Jan 2018 01:23:05 GMT

no it doesn't obviously mean anything of the sort. The fact the chip gets to hardfault (are you even sure it is by the way or is that another guess?) means it's basically working. If the crystal wasn't working it wouldn't matter for the HF one (stays on the RC) and I doubt you've even got to the point of trying to enable the LF one or probably the HF one come to that.

You need to actually debug the hardfault. You need to read the registers and you need to work back to find out why you have hardfaulted. Stop guessing and handwaving about bad hardware, hardfaults leave a trail behind them, follow it.

RE: NRF52832 in Hard Fault State.

soumil — Sat, 20 Jan 2018 04:26:50 GMT

Thanks RK for the answer. As I mentioned in my question as well, I am just initialising one GPIO pin which has a LED connected and toggling it in a while loop in the main function. The Nordic chip goes to a hard fault state even before initialising a GPIO pin. This obviously means that there is something wrong either in the chip or the crystal circuitry? Is this the correct assumption? I am even trying to read the FICR registers but as it enters main, nordic chip goes to a hard fault state.

RE: NRF52832 in Hard Fault State.

soumil — Sat, 20 Jan 2018 04:24:34 GMT

Thanks Dave. As I mentioned in my question as well, I am just initialising one GPIO pin which has a LED connected and toggling it in a while loop in the main function. The Nordic chip goes to a hard fault state even before initialising a GPIO pin. This obviously means that there is something wrong either in the chip or the crystal circuitry?

RE: NRF52832 in Hard Fault State.

RK — Fri, 19 Jan 2018 23:59:05 GMT

See my answer to your other (rather similar) question. If you have a reproducible hardfault you are very lucky because all you need to do is stop the board with a debugger, go look at the registers and stack and work your way backwards.

I don't know where you got this bizarre 'memory corruption' and 'chip replaced' idea from. That's the absolute least likely reason for hardfault.

RE: NRF52832 in Hard Fault State.

Dave_couling — Fri, 19 Jan 2018 18:36:29 GMT

There are a variety of reason why hardfaults occur.

Most common in interrupt priority violations
Referencing an uninitialized potiner
Memory overruns

If you're certain that your code is fine, id look into your crystal circutry. Make sure they are designed correctly and initialized correctly in FW.