USB debug adapter SWD connect with Arm Cortex M3 failure analysis

   There is an issue reported from customer that Silabs USB debug adapter (UDA) cannot
connect with SiM3U1xx MCU card board. When they try to download code into MCU under
preceistion32 IDE, it got below message.

“Error message: 02: Failed on connect: Em(04). Cannot provide power to DAP bus. Emu(0):
Conn&Reset. Was: None. DpID: 2BA01477. Info: UDA000C5EFB”

Once new chip been programmed and UDA cannot connect with MCU any more.

What could cause the connection failure? Normally, set system clock incorrectly or put MCU
into low power mode will cause such issue. So I suggest customer to use si32FlashUtility to erase
internal flash. "si32FlashUtility.exe -r 1 -e 2". In startup code, there is 500ms delay which allows
UDA take control of MCU, and then si32FlashUtility.exe can erase the wrong firmware inside
flash. But things not go smooth. Customer replied that it doesn’t work and error message out:
“ADI_STTUS_API_NOT_CONNECTED_TO_TARGET”. There is weird thing and asked customer
sends their board and source code to me.

Investigating:

Customer’s code Analysis:

I start testing on my board with customer’s code at first. I added back door code to prevent
unexpected situation. Add check GPIO status at beginning of main function.

#include
void check_gpio()
{
SI32_CLKCTRL_A_enable_apb_to_modules_0(SI32_CLKCTRL_0,SI32_CLKCTRL_A_APBCLKG0_P
B0);
while(SI32_PBSTD_A_read_pin(SI32_PBSTD_2,8) == 0);
SI32_PBSTD_A_set_pins_push_pull_output(SI32_PBSTD_2, 0x00000C00);
SI32_PBSTD_A_write_pins_low(SI32_PBSTD_2, 0x00000C00);
SI32_PBCFG_A_enable_crossbar_1(SI32_PBCFG_0);
}

And we also have 500ms delay in Systeminit function by default.

void SystemInit(void)
{
// To disable the pin reset delay described below, make sure the preprocessor
// symbol si32HalOption_disable_pin_reset_delay is defined by your toolchain.
# if !defined(si32HalOption_disable_pin_reset_delay)
// If the reset pin was the source of the last reset, delay for 500 msec.
// Firmware can disable the debug port by inadvertantly setting the AHB
// clock source to a disabled clock. If this happens too quickly after a
// reset, it is not possible for a debug agent to gain control and thus
// not possible to reprogram the on-chip flash. Adding a delay here gives
// a debug agent sufficient time to connect.
if ((SI32_RSTSRC_0->RESETFLAG.PINRF == 1)
&& (SI32_RSTSRC_0->RESETFLAG.PORRF == 0)
&& (SI32_RSTSRC_0->RESETFLAG.VMONRF == 0))

SysTick->VAL = 0;
SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk;

// Wait for the count down to complete
while (0 == (SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk)) {}

// Set the SysTick timer to reset values
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;

}
# endif

// invoke the application's system initialization.
mySystemInit();

}

Run the code and I can see connect failure happened, same as customer’s issue. I ran
"si32FlashUtility.exe -r 1 -e 2", it can erase firmware from internal flash. I just check customer’s
code. I found the reason cause connection failure. They try to make system clock configuration
change to external CMOS. But the setting of the XTAL2 pin is wrong. It set it as analog mode
instead of digital input. So when switch system clock to external CMOS, the MCU hang. And also
ETM enabled by customer. It is not necessary. I just comment out the system clock modification
part. And UDA can connect with MCU card board.

Customer’s board analysis:

But customer’s board cannot be recovered by "si32FlashUtility.exe -r 1 -e 2", what happens
with customer’s board? First, I need to confirm whether customer’s code contains 500ms delay.
This is default routine in SDK. And since customer’s code set ETM enable, this setting will draw
down ETM pin, those pins are high when I press RESET pin. So I can compare RESET and ETM
pin to know whether 500ms delay was executed. And the result shows no 500ms delay at all.
That is why si32FlashUtility cannot erase firmware. I have measure timing of the code execution.
It only takes dozens micro seconds to run from power on to system clock modification part.
I checked si32FlashUtility, it issue reset action on RESET pin, and 4ms later, and it start to
communicate with MCU, the communication period about 50mS. So that insufficient to take
control from MCU.

Solution:

Make sure add back door code in project. Include long delay and GPIO checking.