How to write your question to maximize your chances to find a solution

[Lina_DABASINSKAITE]

The language of this community is English. See reference.

• DON'T put the ENTIRE question in the title. 
• Keep your title short and concise, you add additional information in the Description section.
• Need to insert code? Use this button in the editor to post it. 
  
• Make sure you include a reference to the product concerned and the type of problem:
  1. [Part Number] Always state the FULL Part Number of the product used.
  2. [Environment] Describe the environment used as toolchain and hardware and state the version used.
  3. [Schematics] If it is a custom board --> Share the schematics using “Attach file” option or inserting some image.
  4. [Details] Describe the symptoms observed (examples: error messages, wrong behavior, screenshots of signals…).
  5. [Expected behavior] If the question is related to performance then what is the target.
  6. [How to reproduce] Detail the steps you have taken to get the behavior seen and clarify the set-up [Input, Output].
  7. [Occurrence] Is the problem systematic? If not, state the frequency.
  8. [Sanity checks] What are the checks that you have already performed (example: Have you reviewed the existing examples - GitHub, Cube...).

[BarryWhit]

When forum regulars look at your question, they're looking for a few things:

1. They want to quickly figure out what you're actually asking, so they can decide whether to try and help or move on.

2. They need to know what you're trying to achieve, not just what you tried to do that isn't working out.

3. Once they decide to help, they need as much relevant information as possible. If you include that information it to begin with, you save everyone the trouble of going back and forth asking for further information.

 

[Andrew Neil]

Some general tips here on How To Debug your problem:

https://www.avrfreaks.net/s/topic/a5C3l000000UaFXEA0/t153137?comment=P-1212908

https://www.bytesnap.com/news-blog/debugging-product-design-troubleshooting-guide 

 

Earlier in that first thread, some tips specifically on Debugging Serial Comms:

https://www.avrfreaks.net/s/topic/a5C3l000000UaFXEA0/t153137?comment=P-1212903

Expanded explanation: https://www.avrfreaks.net/s/topic/a5C3l000000UaFXEA0/t153137?comment=P-1212905 

More on UART debugging: https://community.st.com/t5/stm32cubeide-mcus/best-technique-for-viewing-uart-debugging-is-dr-register/td-p/767894 

 

Some tools & tips specifically for STM32:

AN4989: STM32 microcontroller debug toolbox

Design for Debug:

https://www.bytesnap.com/news-blog/debugging-product-design-troubleshooting-guide/#:~:text=According%20to%20Antronics,have%20enough%20resources.

https://www.avrfreaks.net/s/topic/a5C3l000000UaCrEAK/t152971

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

 

How to connect CubeIDE debugger to a running system (or crashed/stuck) without 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

 

#HowToDebug #DebugSerialComms

[Andrew Neil]

When your problem is solved, remember to mark the solution:

https://community.st.com/t5/community-guidelines/help-others-to-solve-their-issues/ta-p/575256

 

[Andrew Neil]

Some general resources on debugging Cortex-M Hard Faults:

https://community.arm.com/support-forums/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault

 

Specifically for STM32 and the CubeIDE:

https://community.st.com/t5/stm32-mcus/how-to-debug-a-hardfault-on-an-arm-cortex-m-stm32/ta-p/672235

 

[Lina_DABASINSKAITE]

Hi @Andrew Neil  and @BarryWhit , great inputs, thanks a lot for sharing them!

[Andrew Neil]

---

@Lina_DABASINSKAITE wrote:

• Need to insert code? Use this button in the editor to post it. 
  

---

If you need to insert text where the layout gets preserved, but without C syntax highlighting, use the 'Preformatted' option under the 'Paragraph' drop-down:

If you don't see that option in the toolbar, use the button to get the extended toolbar:

 

This is useful for stuff like Linker Scripts, text tables, formatted console output, "ASCII Art", etc:

Formatted console output:

# i2cdetect  -y 1 ;
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

 

ASCII-Art:

 +-------------+
 | |
 ------>+ +------>
inputs ------>+ process +------> outputs
 ------>+ +------>
 | |
 +-------------+

 

 

[MohanKrish]

Thank you

[unsigned_char_array]

Another useful thing is stating intent. What is the goal? Often the OP is deeply focused on one specific solution to a bigger problem. Knowing the context can help. Sometimes it's easier to try a simpler solution than to try to get an overly complicated solution to work. If the complex solution is required or desired the OP can state why.

Another useful thing is measurements. Too many times I've read things like "I get weird values" or  "It's too slow". Show me the data. Logic analyzer captures, oscilloscope captures, a graph or table with measurement data, timer values, ADC values etc.