LoRa-E5 STM32 WLE 5JC: i2c doesnt work if not in debug mode [ioc -> debug -> serial/disabled]

[AA.16]

My I2C doesn;t seem to work whenever i turn off debug pins in IOC. I used a diff to see the changes but it seems fine to my untrained eyes:

$ git diff
diff --git a/Core/Inc/sys_conf.h b/Core/Inc/sys_conf.h
index 988f1e8..b3cb386 100644
--- a/Core/Inc/sys_conf.h
+++ b/Core/Inc/sys_conf.h
@@ -75,7 +75,7 @@ extern "C" {
 * @brief Enable/Disable MCU Debugger pins (dbg serial wires)
 * @note by HW serial wires are ON by default, need to put them OFF to save power
 */
-#define DEBUGGER_ENABLED 1
+#define DEBUGGER_ENABLED 0^M
 
 /**
 * @brief Disable Low Power mode
diff --git a/Seeed-LoRa-E5.ioc b/Seeed-LoRa-E5.ioc
index c1059bc..ffbda64 100644
--- a/Seeed-LoRa-E5.ioc
+++ b/Seeed-LoRa-E5.ioc
@@ -199,64 +199,61 @@ Mcu.CPN=STM32WLE5JCI6
 Mcu.Family=STM32WL
 Mcu.IP0=ADC
 Mcu.IP1=ADV_TRACE
-Mcu.IP10=RTC
-Mcu.IP11=SEQUENCER
-Mcu.IP12=SUBGHZ
-Mcu.IP13=SYS
-Mcu.IP14=TIMER
-Mcu.IP15=TINY_LPM
-Mcu.IP16=USART1
-Mcu.IP17=USART2
-Mcu.IP2=DEBUG
-Mcu.IP3=DMA
-Mcu.IP4=I2C2
-Mcu.IP5=LORAWAN
-Mcu.IP6=LPUART1
-Mcu.IP7=MISC
-Mcu.IP8=NVIC
-Mcu.IP9=RCC
-Mcu.IPNb=18
+Mcu.IP10=SEQUENCER
+Mcu.IP11=SUBGHZ
+Mcu.IP12=SYS
+Mcu.IP13=TIMER
+Mcu.IP14=TINY_LPM
+Mcu.IP15=USART1
+Mcu.IP16=USART2
+Mcu.IP2=DMA
+Mcu.IP3=I2C2
+Mcu.IP4=LORAWAN
+Mcu.IP5=LPUART1
+Mcu.IP6=MISC
+Mcu.IP7=NVIC
+Mcu.IP8=RCC
+Mcu.IP9=RTC
+Mcu.IPNb=17
 Mcu.Name=STM32WLE5JCIx
 Mcu.Package=UFBGA73
-Mcu.Pin0=PA14
-Mcu.Pin1=PA15
-Mcu.Pin10=PB14
-Mcu.Pin11=PA10
-Mcu.Pin12=PB5
-Mcu.Pin13=PA0
-Mcu.Pin14=PB6
-Mcu.Pin15=PA9
-Mcu.Pin16=PC1
-Mcu.Pin17=PC0
-Mcu.Pin18=PB0-VDD_TCXO
-Mcu.Pin19=OSC_IN
-Mcu.Pin2=PB15
-Mcu.Pin20=PA3
-Mcu.Pin21=PA2
-Mcu.Pin22=PB10
-Mcu.Pin23=PA4
-Mcu.Pin24=PA5
-Mcu.Pin25=VP_ADC_TempSens_Input
-Mcu.Pin26=VP_ADC_Vref_Input
-Mcu.Pin27=VP_ADV_TRACE_VS_ADV_TRACE
-Mcu.Pin28=VP_LORAWAN_VS_LoRaWAN
-Mcu.Pin29=VP_MISC_VS_MISC
-Mcu.Pin3=PC14-OSC32_IN
-Mcu.Pin30=VP_RTC_VS_RTC_Activate
-Mcu.Pin31=VP_RTC_VS_RTC_Calendar
-Mcu.Pin32=VP_RTC_VS_RTC_Alarm_A_Intern
-Mcu.Pin33=VP_SEQUENCER_VS_SEQUENCER
-Mcu.Pin34=VP_SUBGHZ_VS_SUBGHZ
-Mcu.Pin35=VP_SYS_VS_Systick
-Mcu.Pin36=VP_TIMER_VS_TIMER
-Mcu.Pin37=VP_TINY_LPM_VS_TINY_LPM
-Mcu.Pin4=PA13
-Mcu.Pin5=PB3
-Mcu.Pin6=PB4
-Mcu.Pin7=PB7
-Mcu.Pin8=PB9
-Mcu.Pin9=PC15-OSC32_OUT
-Mcu.PinsNb=38
+Mcu.Pin0=PA15
+Mcu.Pin1=PB15
+Mcu.Pin10=PB5
+Mcu.Pin11=PA0
+Mcu.Pin12=PB6
+Mcu.Pin13=PA9
+Mcu.Pin14=PC1
+Mcu.Pin15=PC0
+Mcu.Pin16=PB0-VDD_TCXO
+Mcu.Pin17=OSC_IN
+Mcu.Pin18=PA3
+Mcu.Pin19=PA2
+Mcu.Pin2=PC14-OSC32_IN
+Mcu.Pin20=PB10
+Mcu.Pin21=PA4
+Mcu.Pin22=PA5
+Mcu.Pin23=VP_ADC_TempSens_Input
+Mcu.Pin24=VP_ADC_Vref_Input
+Mcu.Pin25=VP_ADV_TRACE_VS_ADV_TRACE
+Mcu.Pin26=VP_LORAWAN_VS_LoRaWAN
+Mcu.Pin27=VP_MISC_VS_MISC
+Mcu.Pin28=VP_RTC_VS_RTC_Activate
+Mcu.Pin29=VP_RTC_VS_RTC_Calendar
+Mcu.Pin3=PB3
+Mcu.Pin30=VP_RTC_VS_RTC_Alarm_A_Intern
+Mcu.Pin31=VP_SEQUENCER_VS_SEQUENCER
+Mcu.Pin32=VP_SUBGHZ_VS_SUBGHZ
+Mcu.Pin33=VP_SYS_VS_Systick
+Mcu.Pin34=VP_TIMER_VS_TIMER
+Mcu.Pin35=VP_TINY_LPM_VS_TINY_LPM
+Mcu.Pin4=PB4
+Mcu.Pin5=PB7
+Mcu.Pin6=PB9
+Mcu.Pin7=PC15-OSC32_OUT
+Mcu.Pin8=PB14
+Mcu.Pin9=PA10
+Mcu.PinsNb=36
 Mcu.ThirdPartyNb=0
 Mcu.UserConstants=RTC_N_PREDIV_S,10;RTC_PREDIV_S,((1<<RTC_N_PREDIV_S)-1);RTC_PREDIV_A,((1<<(15-RTC_N_PREDIV_S))-1)
 Mcu.UserName=STM32WLE5JCIx
@@ -298,10 +295,6 @@ PA10.GPIO_Label=BQ_ALERT
 PA10.GPIO_PuPd=GPIO_NOPULL
 PA10.Locked=true
 PA10.Signal=GPXTI10
-PA13.Mode=Serial_Wire
-PA13.Signal=DEBUG_JTMS-SWDIO
-PA14.Mode=Serial_Wire
-PA14.Signal=DEBUG_JTCK-SWCLK
 PA15.Locked=true
 PA15.Mode=I2C
 PA15.Signal=I2C2_SDA

im using the following code to wait for another chip to wake up. when debug is activated it works fine but when debug is tuned off it doesn;t work and is forever waiting for I2C:

//wait for i2c to activate
	while (HAL_I2C_IsDeviceReady(&hi2c2, hbat1.address_i2c, 3, 5)) {
		//TODO i2c doesnt work if not in debug mode - ioc debug -> serial/disabled
		HAL_Delay(BAT_DELAY_WHILE_LOOP);
	}

I am at the end of my ideas. What is causing this?

Also i did use the following around my I2C code to prevent the device frmo going into sleep mode:

	//start the active power counter
	UTIL_LPM_SetStopMode((1 << CFG_LPM_BAT_MANAGER), UTIL_LPM_DISABLE);
	//do the I2C code here
 i2c_code();
	UTIL_LPM_SetStopMode((1 << CFG_LPM_BAT_MANAGER), UTIL_LPM_ENABLE);

I did use a logic analyzer to see if anything is sent from the STM and no luck. Both SDA and SCL stay high and don't go down ever.

Why is that? its also hard to debug with the debug turned off.

[AA.16]

Anyone can point me to the Solution? i am pulling my hair out over this.

[Tesla DeLorean]

>>its also hard to debug with the debug turned off.

Use a serial port, add diagnostic and telemetry. Or perhaps methods where you can query and report internal conditions and states?

Check that the GPIOA clock is initialized. The debugger might be initializing things you later depend on. Walk thru the initialization, check the ordering is correct, clocks need to be running before peripherals / pins will take configuration.

Check there aren't any dependencies on delays or timing

Report I2C peripheral state, and any errors or status reported by the HAL functions.

[AA.16]

Use a serial port, add diagnostic and telemetry. Or perhaps methods where you can query and report internal conditions and states?

how would i do that?

I am using a function called APP_LOG that can print via uart. I did print a few things:

1. HAL_I2C_IsDeviceReady returns HAL_ERROR
2. hi2c2.State is 32 (printed as an int with %d)
3. hi2c2.ErrorCode is 32 (printed as an int with %d)

both sdl and scl stay on high. during all of the test.

I have this code in the main:

 
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();
 
 /* USER CODE BEGIN Init */
	__HAL_RCC_GPIOB_CLK_ENABLE();
	__HAL_RCC_GPIOA_CLK_ENABLE();
 /* USER CODE END Init */
 
 /* Configure the system clock */
 SystemClock_Config();

how can i

>Check there aren't any dependencies on delays or timing

[Tesla DeLorean]

Have the software engineer(s) on the project code some routines that unpack peripheral settings, or can accept PEEK/POKE type interaction from a terminal so you have some visibility internally. How pretty or crude that is depend on the effort applied, and the quickness of coming to some resolution of the problem. Perhaps have a menu of options, so that with each build you can test multiple ideas, I'm not from the change one thing at a time school of coding.

Print out AHB,APB clock speeds, perhaps dump a handful of related RCC registers. You're trying to output enough information so you can compare-n-contrast where the system works, and where it doesn't.

Pins not changing, does suggest an issue with the pin level configurations, association or clocking.

Is there some code in there that explicitly disables the PA13, PA14, PA15 to preclude debugging?

Add additional delays at different points in the code,see if you can arrive at some particular failure points, and bisect. Change the timing, see if the issue moves or changes in a way that suggests a cause or area to focus on.

[AA.16]

Reinitializing the i2c after a stopmode2 solved the issue