uart request response just during debug and debugger connected

[carleslsregner]

Hello people,

I have been developing a firmware to be used in the stm32g051. One of the features is the ability to respon to request to get information from the uC. I used dma for the uart1 tx and rx.  I was happily developing and testing the new feature added into the stm32g051. Then when I use it without the debugger, it is unable to stablish communications between the PC and the microcontroller. 

The curious thing is the fact that I remove the debugger -I disconnect it- and the communication still works. It is the "reset" without debugger what is unable to stablish the connection.  

I change the clocks following the several  post regarding this problem but the solution still eludes me. 

[Andrew Neil]

---

@carleslsregner wrote:

The curious thing is the fact that I remove the debugger - I disconnect it - and the communication still works. It is the "reset" without debugger what is unable to stablish the connection.  

---

Sounds like some timing issue in your startup: the startup will be slower in the debugger.

Instrument your code so that you can see what's happening during startup independent of having the debugger connected.

Note that you can connect to a running (or "crashed") system without doing a reset or flash programming:

https://community.st.com/t5/stm32-mcus-embedded-software/processor-stuck-if-i-run-code-without-debugger/m-p/802267/highlight/true#M63401

PS:

More on "instrumenting your code" here (from that same thread).

[carleslsregner]

That's a good idea that I miss. I will try right now!

[carleslsregner]

It is curious. I have never enabled the wwdg but it is being triggered. 

[Andrew Neil]

So, again, instrument your code to see how it gets there.

[Guenael Cadier]

Hi @carleslsregner 

What you see in debugger could indicate that you are falling in an interrupt handler which is not defined. What I mean is the interrupt that leads you there is not necessarly the WWDG interrupt.

Regards

[TDK]

You can look at the VECTACTIVE field in the SCB registers to find out which interrupt it's in. Subtract 16 from the value and compare to IRQn_Type.

[Pavel A.]

The debugger screenshot hints that you're using semihosting. if so your program cannot run without debugger. Make a "release" configuration without semihosting.

[carleslsregner]

I will us this to get the VECTACTIVE

uint32_t ipsr = __get_IPSR(); 

[carleslsregner]

I do not found the vector interruption but I isolated the problem module by module. It seems the code below is what causes the error. I didn't not found the error, but I found the solution. But yes, it seems related to the PVD (power voltage drop) interruption. 

#include "supply_drop_hw.h"

mid_error_void_p_callback_t drop_callback_hw = NULL;

void HAL_PWREx_PVD_Falling_Callback(void)
{
	// This function is called when the power voltage detection event occurs
	// Implement your logic here, e.g., log the event, take safety measures, etc.
	//status_store_status(); // Store the current status to non-volatile memory
	drop_callback_hw();
}


static void MX_PWR_PVD_Init(void)
{
    PWR_PVDTypeDef sConfigPVD;

    sConfigPVD.PVDLevel = PWR_PVDLEVEL_6; // Approx 2.9V threshold
    sConfigPVD.Mode = PWR_PVD_MODE_IT_FALLING; // Interrupt on voltage rise or fall
    HAL_PWR_ConfigPVD(&sConfigPVD);
    HAL_PWR_EnablePVD();

    // Enable and set PVD Interrupt to highest priority
    HAL_NVIC_SetPriority(PVD_IRQn, 0, 0);
    HAL_NVIC_EnableIRQ(PVD_IRQn);
}


mid_error_t supply_drop_hw_init(mid_error_void_p_callback_t callback_in)
{
	drop_callback_hw = callback_in;
	MX_PWR_PVD_Init();
	return MID_ERROR_OK;
}

Thank you anyway.