We have 2 identical development boards and have been using only one until now. I was able to download code into the 2nd board successfully but it will not run. It does not run in either standalone or debug mode (PICKit3). What are the likely causes?
We have 2 identical development boards and have been using only one until now. I was able to download code into the 2nd board successfully but it will not run. It does not run in either standalone or debug mode (PICKit3). What are the likely causes?
Can you post the schematic?
If some of the decoupling capacitors are no connected or shorted, the MCU may fail. The MCU core runs on a separate power domain. Programming of the flash doesn't involve the MCU so even if you can program it, the HW may cause it to fail when the MCU starts.
The problem can also be soldering under the chip, CSP parts can be tricky sometimes. See if a reflow solves the problem. Or have the board x-ray'ed.
Comparing the crystal input to the MCU indicates that on a working board there is a signal (albeit distorted and at a much lower frequency because the probe is pulling it). But on the bad board nothing - sitting firmly at 0V.
Also checked the supply voltage at one of the caps (C3) and it is 3V as expected. The MCU pins are too small to probe but inspection under a microscope shows that this cap is tied to the MCU pin. I think that eliminates the "shorted decoupling cap" issue.
Also verified that SWDIO/RESET- is 3V (i.e. not held in reset).
SWDCLK and SWDIO are used to program the flash so the MCU is not involved (I agree). But if the flash can be programmed does that not prove that the chip is powered correctly? If that is true, then it seems the problem is a faulty MCU.
In light of the above, please expand on your thought that the soldering may be an issue. Unfortunately I do now have the ability to reflow or X-ray the board.
on the bad board nothing - sitting firmly at 0V.
So what happens if you change your code to use the internal oscillator?
Why didn't I think of that? Actually I did but since the external crystal is required for the radio I dismissed it.
In order to try resolving the board problem I attempted to select the internal RC 16MHz clock but was unable to do it. It looks like something like the following must be in the code (but I don't know where to put it). I would think it should be in the startup code???
NRF_CLOCK->HFCLKSTAT = 0x00010000; // HFCLK running, use 16MHz RC oscillator
Default is 16 MHz RC so if you haven't changed it, it should startup with that. If you have specifically changed to the 16 MHz XO, the MCU will hang while waiting for the crystal to start. If this is the case, check the crystal connection and the load caps.
Default is 16 MHz RC so if you haven't changed it, it should startup with that. If you have specifically changed to the 16 MHz XO, the MCU will hang while waiting for the crystal to start. If this is the case, check the crystal connection and the load caps.
That makes sense. If there is no external crystal connected it needs a clock from somewhere - hence the internal RC. I am not (knowingly) changing the the external crystal. I have searched for "HFCLKSTAT" and it is nowhere to be found in the project. So I assume that means it is running off the internal RC, correct?
My understanding is that the radio requires the more accurate crystal. But the radio is working fine. That's why I thought the external crystal was in use.
If it is using the RC oscillator then the clock is not the problem.
How do I switch to the external oscillator? As stated before, where should code be located (startup or main code) and what are the instructions? Load NRF_CLOCK->HFCLKSTAT?
Hi,
To see if the external HFCLK starts up, you can trigger it manually, by adding this at the top of your main (before softdevice init):
NRF_CLOCK->TASKS_HFCLKSTART = 1; while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0); NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
If it hangs in the while-loop, it has problems starting up the xtal.
When you enter debug mode, where does it stop when you break/pause the debug session? Have you remembered to program the softdevice onto the device?
Kind regards,
Håkon
I placed a breakpoint at the first instruction in main(). After clicking on RUN icon it immediately stops and never gets to the breakpoint.
I inserted the 3-line test code you offered and placed breakpoints at every line. It doesn't stop at any of them. Again, after clicking on RUN it immediately stops. Clearly it is not running at all.
No, I have not installed the softdevice. I am assuming that it should run basic code without it. Of course without it the BLE will not work - but that is not an issue right now.
Can the softdevice be written using uVision or must nRFgo Studio be used? It has been a long time since I used nRFgo Studio so I don't remember the physical connections. Can I use the Segger programmer/emulator connected to SWDIO and SWDCLK on the target to write the softdevice. If I remember correctly there may have been a different cable that I used with nRFg Studio.
In debug mode, even when the breakpoint is at the 1st or 2nd line in main(), it immediately stops after clicking RUN but never gets to the break.
I added the 3 code lines suggested and put breaks on each line. But it never reached any of them. Just stops after clicking RUN. Clearly the MCU is not running.
No, the softdevice has not been loaded. Shouldn't that just affect BT? Shouldn't the MCU run instructions without it?
It has been so long since I loaded the softdevice on targets I forgot how though I do know that nRFgo Studio was used. I just unsuccessfully tried using nRFgo with the Segger JTAG. If I remember correctly there is other hardware used for this purpose. What is it?
Hi,
My apologies for the delayed answer.
If your application does not rely on the SoftDevice, you can then omit it.
A softdevice application will be offset wrt. to flash and RAM, like 0x18000 for flash and 0x20002000 for RAM. If there is no softdevice present in flash then, you will never start your application, as there's nothing at address 0 (and onward).
Tom said:I placed a breakpoint at the first instruction in main(). After clicking on RUN icon it immediately stops and never gets to the breakpoint.
Where is it stuck if you break (or pause) the debug session?
Tom said:I just unsuccessfully tried using nRFgo with the Segger JTAG. If I remember correctly there is other hardware used for this purpose. What is it?
Try using nrfjprog directly:
nrfjprog -e # this will erase the device
nrfjprog --program <hex file> -f nrf51 --reset # program a .hex and reset the device afterwards.
Kind regards,
Håkon