Halt and Catch Fire (code killing nRF52840)

RE: Halt and Catch Fire (code killing nRF52840)

Pascal_PIEU — Mon, 01 Mar 2021 15:01:02 GMT

good to see your problems seemed solved!

Have you tried updating Segger drivers manually on the first PC and try it again?

RE: Halt and Catch Fire (code killing nRF52840)

benmack — Mon, 01 Mar 2021 12:16:03 GMT

A brief update - I think I've solved my problem

Early days, I want to do lots of testing, but seems to be related to my PC or USB ports. Tried programming target from my laptop and it is now working fine... doh!

Very very strange, as it seemed to be entirely reproducible and seemed to be a result of a very specific sequence of project updates. And of course some misleading error messages about target voltage...

I'll post more here once I've done more testing, just wanted to let you know ASAP so I'm not wasting peoples time

RE: Halt and Catch Fire (code killing nRF52840)

benmack — Mon, 01 Mar 2021 11:33:11 GMT

OK the plot thickens... I'm not sure what is happening here, wondering if the J-Link OB is the cause of the problem.

I've been experimenting with the nRF Connect Progammer (latest v1.4.8), connected via the eval board J-Link OB to our new target hardware (i.e. not the target on the eval board). I can load our non-BLE application to the target absolutley fine, and it runs. However if I erase the target then try loading the softdevice hex file, then the load fails. This is JUST the softdevice, no application code at all:-

nRF5_SDK_17.0.2_d674dde\components\softdevice\s140\hex\s140_nrf52_7.2.0_softdevice.hex

Here's the log file from nRF Connect Programmer:-

https://www.dropbox.com/s/1mqmo7vdmf7ac69/2021-03-01T10_38_38.221Z-log.txt

10:40 tried loading Z:\prefect\ds1241-sensus-pcu\sw\snap12\Output\Debug\Exe\ds1241.hex - loads fine and runs
10:41 tried loading ONLY softdevice, fails (errors start at T10:42:01.01)

No mention in the log of any target voltage problems, but it does give lots of JLINK_HasError() messages.

The Panasonic PAN1780 eval boards have J-Link OB-SAM3U128 V3 compiled Jul 3 2020 10:46:22

I have two eval boards here, both do the same so I'd be surprised if it is a hardware problem. I have more arriving today. Or I could buy a normal jlink, just to check it isn't the OB ones.

Any ideas would be very welcome here, I'm up against deadlines...

RE: Halt and Catch Fire (code killing nRF52840)

benmack — Mon, 01 Mar 2021 07:50:49 GMT

OK this is possibly a clue...

I went back to working on my non-BLE project. This was originally based on SDK\examples\peripheral\blinky\pca10056 - the proj.emProject was derived from that and it uses that flash_placement.xml file. Running on our new PCB prototypes, not an eval board. This has been working fine, developed a bunch of non-BLE app code, all good.

This morning I accidentally built and loaded my target with this code, but using the flash_placement.xml file from SDK\examples\ble_peripheral\ble_app_blinky (in other words it has the reserved flash and ram areas for a softdevice). No other changes, project not loading a softdevice. The J-Link loader died in exactly the same way, while loading target:-

Preparing target for download
Executing Reset script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading ‘ds1241.elf’ to J-Link
Programming 14.7 KB of addresses 00000000 — 00003b03
Programming 0.0 KB of addresses 00003b04 — 00003b07
Target voltage too low (1 Volt is required, Measured: 0.0 Volt).
Download failed

I don't fully understand what is going on here, I'm a newbie to nRF stuff. I've read the basics about this here...

https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory

I'm guessing this means it put my application code in flash in the reserved area gfor the softdevice, so it wouldn't run? But why would that cause a "Target voltage too low" error, and cause the J-Link to disconnect?

By the way I put a scope on the target 3V3 rail while loading this, and it is solid 3V3, doesn't dip. Similarly when I try loading the softdevice into an eval board.

Any thoughts?