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

Lina_DABASINSKAITE · ‎2023-07-18

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 · ‎2024-07-06

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 · ‎2024-08-08

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 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

#HowToDebug #DebugSerialComms

Andrew Neil · ‎2024-08-08

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 · ‎2024-08-12

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 · ‎2024-08-20

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

Andrew Neil · ‎2024-09-27

@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 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 · ‎2024-10-09

Thank you

unsigned_char_array · ‎2025-03-21

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 then 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.