- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
05-29-2015 02:44 AM
I have an application running on a target board where I'd like to attach the debugger to.
I can do this software-wise in Simplicity Studio by selecting Run > Attach History.
However, before doing so I of course need to attach the debug connector to the target board. I'm using a Leopard Gecko starter kit as debugger. I notice that when I connect the debugger sometimes the controller on the target board is reset and sometimes it is not. Of course I would like to connect to the hardware without resetting it so that I can see the state the controller is in, as I'm trying to debug an 'feature' that only happens now and then.
The circuit on the target board is implemented as is described in AN0002, with short traces from the relevant pins to the debug connector. There is no additional circuitry on the reset pin. The power supply on the board is a stable 3V0, power comes from a battery. The debugger is connected to my computer over USB and gets its power supply from there.
Is there a way to ensure that when connecting the debugger to the target board the controller on the target board is not reset? Are other people experiencing this when connecting the debugger to a target board?
Solved! Go to Solution.
05-29-2015 03:56 AM
By all means, I'm no expert in this, but I think this comes down to how JLink identifies targets. If it can't immediately understand what's on the other end of the line, it will issue a reset and try again.
1) Is it possible to just leave the cables connected, but with no debug session open, so that you can just initiate the debug session when you observe your 'feature'?
2) Can you connect the debug-wires, but not the reset-pin? (You can find the pin-out of the debug-connector in the STK user guide). This usually works for debugging, but you might have problems identifying targets and flashing the device when the reset-pin is not connected.
05-29-2015 06:03 AM
Thanks for the responses!
@Alf the problem occurs when I attach the debug connector, so I don't think that the target identification has something to do with it, as this identification will only be activated when I start the operation in the software (I assume, unless the debugger starts that identification automatically when it notices a connection to the debug port?).
Regarding (2) : yes good point, this is certainly something I can try.
@vanmierlo making a good GND connection first is indeed something I suspect what is going wrong at certain times. I noticed I can reduce the likelihood of triggering the reset when I plug the debug connector on the board in a certain specific way.
Time to add some jumper cables between the target board and the debugger hardware. I'll report back when I have more info.
05-29-2015 12:37 PM
in the mean time I've attached a scope to see what is going on with the reset pin when I connect the debugger connector. See attachment, there is indeed a transient on the reset line that causes the controller to reset.
I think it is related to the order in which the pins of the connector make contact with the board (the connector I'm using is a TC2030 so it is easy to have one pin make contact before another one).
I tried with the reset line not connected to the debug connector and this improves the situation to a big extent but I still can trigger a reset once in a while.
If I connect the debug connector first to the board, and only in a second step connect the debugger cable to the programmer (that has a connector that mechanically ensures all pins are connected at the same time) the resets also happen a lot less frequently.
So it seems that the problem is indeed related to actually making the physical connection between the target board and the debugger. Making this connection carefully (connect ground first, and use a stable connector) reduces the chance of resting your target board by connecting the debugger to it.
05-30-2015 03:53 PM
There is a level shifter that is powered from the target's VCC, controlling output pins including reset IIRC. So you must connect VCC and GND first, a bit like USB does.
06-04-2015 09:48 AM