[SOLVED] Debug+trace connector for SiLabs EFR32BG22

Hello,

I am trying to build the 19 pin debug+trace connector for a Silicon Labs EFR32BG22.Here is the link to the reference manual for that part:

https://www.silabs.com/documents/publ…fr32xg22-rm.pdf

(Please do not think I expect you to read this, it is only for reference)

I used this link to describe the debug+trace connector:

https://wiki.segger.com/19-pin_JTAG/SWD_and_Trace_Connector

Here is the connection list I have created:

The above table is supposed to look like the 19-pin connector with pins down the middle and connections to EFR32BG22 outside of each pin. As you can see, I am not a good artist.

Questions:

• Pin 1 provides a voltage reference for Segger equipment.Is 1.8 volts acceptable?This is my main CPU core voltage and I/O domain.I couldn’t find the electrical specifications for that signal.I see the Supply Adapter has a voltage range of 1.2 volts to 5.0 volts for VTref, is that what Segger equipment allows?
• On this processor, the SWV pin and TRACEDATA0 pin are shared on the same physical pin (PA03).Will this work for ETM tracing?What does this mean if I am using SWD for debugging?Is the only impact to lose debug printing through the serial wire viewer output pin?
  
• I am using a 20 Mhz clock for most work and 39 MHz when Bluetooth is active. My typical usage is to wake up 5 to 10 times per second and run for about 400 microseconds. Do you think the trace buffer will overflow if I only have one TRACEDATA pin?

Do you have any other recommendations for this?

Alex,

Thanks for your quick reply.

As far as I know, there is only either the 20 MHz RC oscillator running or the 39 MHz crystal running. We are not using any special clocking like the clock multiplier or divider, one of those frequencies are the main CPU clock when waking up. There isn't any other fixed 8Mhz clock or similar thing on these boards or internal within the CPU. I would assume trace clock is running at half the CPU, or whatever is usual for it.

We are currently waiting for the connector board to come back to try this on our target board.

Our application is extremely power sensitive and we spend as much time as possible in low energy sleep.

I can confirm the connector shown above worked for us on the BG22. You have to slow HCLK down by a factor of 8x to allow ETM enough time to keep up with the data rate from the trace. I did that with this line:

//
//
//
   CMU_ClockDivSet(cmuClock_HCLK, 8);      //  Divide HCLK by 8 to slow down the CPU and allow ETM more time