Debugging external nRF51422

RE: Debugging external nRF51422

swoud — Tue, 13 Sep 2016 00:07:19 GMT

Hi, could you please refer to my update and give me some suggestions?

RE: Debugging external nRF51422

swoud — Mon, 12 Sep 2016 04:58:40 GMT

Hi, thanks for your reply. I am sorry but I know quite little about software part. Could you please guide me how to connect to the target chip via JLink command line? Thanks a lot.

RE: Debugging external nRF51422

RK — Mon, 12 Sep 2016 04:28:47 GMT

No there is no reason for this - it works - therefore either you have not connected it properly or you have misidentified which board you are connected to and it has in fact bypassed it, or you blew something up whilst trying it out .

Again - use the JLink command line to read the FICR on the chip to work out what you are actually connected to in each case.

RE: Debugging external nRF51422

swoud — Mon, 12 Sep 2016 04:25:38 GMT

Hi, what confuses me is that, when the pin1 of P19 is supplied with high voltage while pin10 is connected to the GND, the DK should bypass the internal chip, however, it doesn't. is there any reason for this?

RE: Debugging external nRF51422

RK — Mon, 12 Sep 2016 03:14:57 GMT

I have no more ideas and your explainaion about the serial port was too contorted to understand. I am however telling you that if the debugger is connected during programming then it's connected during debugging, they are one and the same thing. It's either connected, or it's not connected.

Try using JLink from the command line to go read the FICR where the unique MAC address of the chip is, that will tell you which chip you are actually talking to

RE: Debugging external nRF51422

swoud — Mon, 12 Sep 2016 01:24:56 GMT

Hi, I did change to P19 for programming, but the same problem still exists, the code is uploaded to the external chip but the debugging is directed to the internal one. Here is how I judge it (if the code is uploaded correctly, it will print on the serial port): 1. Connecting all the cables from P19 to the external board; 2. Powering on the external board and programming it from the DK; 3. Monitoring from the serial port shows nothing; 4. Disconnect only SWCLK signal from the external board, programming failed; 5. Disconnecting the whole external board, and programming the DK; 6. The serial port is printing normally; 7. Reconnecting the external board to P19, the serial port still works normally; So from above steps, I can tell the programming function works fine, but the debugging does not. I measured the voltage on Pin1 of P19, it is 3.3V, so I suspect the DK should bypass the internal chip. Would you please guide me on this? Many thanks.

RE: Debugging external nRF51422

swoud — Sun, 11 Sep 2016 04:29:21 GMT

Many thanks. I will use P19 instead and see whether it would recover this problem.

RE: Debugging external nRF51422

RK — Sun, 11 Sep 2016 04:17:18 GMT

programming and debugging are exactly the same - if it's connected to the external one for programming, it's connected to the external one for debugging also, it's all done via the exact same interface. So I doubt you are seeing what you think you are seeing.

And I have no idea whether it's related to P19 vs P20, however P19 is the standard debug out, P20 is really designed for debugging things connected via arduino shields and if you check the links I pointed you to you will see lots of people have failed to use P20

RE: Debugging external nRF51422

swoud — Sun, 11 Sep 2016 04:07:16 GMT

Thanks for your help and reply. What really confuse me is that the DK can actually programme the external chip, but the debugged target is not correct (I can tell it is debugging the internal one). Does this problem relate to whether pin19 or P20 I am selecting? Many thanks.

RE: Debugging external nRF51422

RK — Sun, 11 Sep 2016 01:55:14 GMT

Type 'P20' into the search box and read some of the previous threads about the difficulties of using P20 over P19. P20 is really designed for arduino shield debugging, P19 is the real debug out. There are a couple of suggestions in those threads which include shorting a couple of pins together. The best suggestion however is to use P19, the header which is actually designed for debug out.