2022-08-08 07:59 AM
Hi,
I wrote an application for the BME680 sensor on the LoRa-e5 (based on STM32WLE5JC).
At the begin everything works normal but after about 70 minutes no more messages come to uart.
in the Error Log I got this message:
eclipse.buildId=Version 1.10.1
java.version=11.0.14.1
java.vendor=Eclipse Adoptium
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_AT
Command-line arguments: -os win32 -ws win32 -arch x86_64
org.eclipse.cdt.dsf.gdb
Error
Mon Aug 08 14:13:47 CEST 2022
Error in final launch sequence:
Failed to execute MI command:
target remote localhost:61234
Error message from debugger back end:
localhost:61234: Connection timed out.
org.eclipse.core.runtime.CoreException: Failed to execute MI command:
target remote localhost:61234
Error message from debugger back end:
localhost:61234: Connection timed out.
at org.eclipse.cdt.dsf.concurrent.Query.get(Query.java:112)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:252)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:109)
at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:97)
at com.st.stm32cube.ide.mcu.debug.launch.DSFDelegate.launch(DSFDelegate.java:328)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:803)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:716)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1021)
at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1224)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.Exception: localhost:61234: Connection timed out.
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:1024)
at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:853)
What can be the problem?
Johannes
2022-08-08 09:58 AM
Seems you monitor it over debuger . This isnt normal way to use.
Activate only UART....
2022-08-08 10:02 AM
I have the same problem if I try only UART. After 70 minutes no more measurments comes over UART.
I dont know how debugging in run mode to see whats happen if it's stop.
2022-08-08 10:22 AM
I'd guess you'd need to instrument your code to understand what mode it's in, or if its gone to sleep. You could make a simple UART based monitor app to respond to queries on internal states or whatever.
Make sure ErrorHandler() and HardFault_Handler() output some actionable data rather than die silently in a while(1) loop.
Consider also a Watchdog, to recover, and establish where the issue might be.
2022-08-08 10:52 AM
thanks for your answer. Do you have examples for me of the ErrorHandler() and the HardFault_Handler()?
2022-08-08 11:02 AM
I've posted examples of a hard fault handler on multiple occasions.
For an error handler, pass in the __FILE__ and __LINE__ data, and print it. That way you can run those down in your source quickly.
2022-08-10 01:29 AM
Hi,
I've integrated the HardFault handler (works with div by 0) but i dont get a Hardfault in my code. I also didn't get an ErrorHandler error.
What can I do now?
2022-08-10 03:16 AM
As I write , debuger isnt designed for this. Change or check your environment, change USB cable , port , no HUB , ...
Somethink (ESD, EMC , ... ) kill your debuger session ...
And good is blink with led on some code places for info when system hangs.
NEXT IS USE WATCHDOG to if problem occurs code reboots.
Next classic mistake is if counter value is ? And counter overload back to zero.
Sometimes after 70 min ...