My Code does not start for a while, and automatically starts, I want to know reason behind this behavior

[Samcet]

Hello Everyone,

For some reason my STM32F407 MCU with specific board has problematic issues in the start. If I connect 3 different cards to its UART channels, which utilizes DMA, it does not start directly and after a while (which corresponds to 1 sec - 60 sec interval) it starts somehow.

If I do not connect the other cards, even though 2 of them are not powered up in the start of the code, there would not be any problem. Also this problem generally arises when I switch the power of the card too fast (1-5 secs)

Another strange behaviour is that the STM32F407 look like it sends garbage value from its UART channels even though the code is not there.

I did not encounter with this problem in debug mode (I mean with STLink and StmIDE), however and I work with debug configurations too when I encounter with this.

I did some experments and it felt like it does not start into the main code because I put a simple red light switch at the very beginning of main() function ( literally GPIO configs then setting the led) and the LED does not go on when the problem starts.

Also after my researches it feels like mayhaps code starts in the different area(NMI Fault handler etc...) but I could not see this in debug as I mentioned before.

I would gladly accept any suggestions and read opinions about the topic.

Thanks in advance,

Regards

Samcet

[HA.5]

Hi Samcet,

the Problem is by sending Data or receiving?

[Samcet]

I could not understand your question. Main problem over here is the code does not start as it is supposed to be.

In terms of communication, my MCU sends garbage data after another MCU sends a message to it from UART channel.

[Karl Yamashita]

When you say specific board, sounds like a custom board. Start by checking the clock signal is working and your clock selection matches the oscillator type. Are you using CubeIDE or MX to generate the initializing code?

[Samcet]

Yes I do use a custom board. The code generation is done by CubeIDE user inteface (.ioc) and the generated code is used for initialization.

In terms of clock signal, I could not understand why this system works as expected in some situations, if there is a clocking problem. Do you mean checking the signal by utilizing a scope ?

The system works as expected when the custom card is powered on at first. There won't be any problem if the power off - on procedure lasts longer than 10 seconds. Even if this is the case, the problem does not arise in some situations.

[Uwe Bonnes]

Consider also a slow starting crystal

[ONadr.1]

Is the bootloader enabled? In that case, some unstable signal to the UART (from uppowered card) could be causing the described behavior.

[Samcet]

According to this list (RM0090), I am using Main Flash Memory configuration, which I believe means that I do not use any specific bootloader. I did not also write any code for bootloader.

I also slightly believe that I do not use any combinations that is in the bootloader activation patterns (at least I believe) (AN2606).

[Samcet]

Do you think that using high speed PLLCLK (SYSCLK 168 MHz) may result in this kind of behaviour ?

I am using the maximum frequencies that is allowed to be used. I will update here when I have the opportunity to try this.

[ONadr.1]

Well, that's pretty weird. I would focus on the differences in the working-not-working state. Supply voltage, oscillator ramp-up, pin voltage levels.

Since the debugger affects this behavior, I would try to generate sequences on some pin to go through individual nodes of the code and I would monitor with an oscilloscope or a log. analyzer where the problem occurs.