[SOLVED] Debug+trace connector for SiLabs EFR32BG22

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [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:

    silabs.com/documents/public/re…-manuals/efr32xg22-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:

    wiki.segger.com/19-pin_JTAG/SWD_and_Trace_Connector



    Here is the connection list I have created:

    Name
    EFR32BG22
    Pin
    Pin
    EFR32BG22
    Name
    VtargetReference
    1.8 Volts
    1
    2
    PA02
    TMS/SWDIO
    Ground
    3
    4
    PA01
    TCK/SWCLK
    Ground
    5
    6
    PA03
    SWV
    Blocking Key
    NC
    7
    8
    NC
    TDI (Test Data Input) JTAG pin, not used for SWD
    Not used
    NC
    9
    10
    nRESET
    Reset pin
    USB5V0
    target power
    11
    12
    PA04
    TRACECLK
    USB5V0
    target power
    13
    14
    PA03
    TRACEDATA0
    Ground
    15
    16
    NC
    TRACEDATA1
    Ground
    17
    18
    NC
    TRACEDATA2
    Ground
    19
    20
    NC
    TRACEDATA3



    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?
  • Hi,

    to 1)
    See here:
    segger.com/products/debug-prob…#technical-specifications
    and look for VIF.
    1.2 - 5V are fine for VIF (VTref)

    to 2)
    While it is a bit unusual to shared TRACED0 with SWV because SWV is usually shared with TDO,
    I can see why SiLabs did it.
    As their EFM32 do not support JTAG, there is no TDO signal to be shared with.
    Actually, sharing SWV with TRACED0 is a clever move because you so not lose anything.
    If you enable & use trace, the SWV data is merged into the trace stream and also transmitted via TRACED0-3.
    So when using trace, the SWV pin becomes obsolete.

    to 3)
    Has a fair chance to work with TRACED0 only.
    It heavily depends on the application how good the trace unit can compress the data.
    But I see a 39 MHz CPU speed not really as critical.
    Do you know the source of the trace clock for these chips?
    Is it 1/2 CPU speed or some “fixed 8 MHz clock”?
    If it is 1/2 CPU speed, 1 trace pin could work with a high chance.
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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:


    Source Code

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