224 views
in Embedded Wizard Studio by
Hi, I use EW Pro Version 9.30 to develop my application on STM32F407. First-page used to show a logo, after that it is called the second page by the command SwitchToDialog. The second page receives a signal from GPIO and calls SwitchToDiaglo to show a menu page. The menu page receives a signal from Other GPIO and calls SwithcToDialog back to the second page. I found STM32F407 is going to Hard fault after switching pages around 8 times.

Why does it happen? How to solve a problem? Please help Thank you.

https://drive.google.com/file/d/1N1alY-d1P056ni5Rhl0SQ2kcDwlUZVT0/view?usp=sharing

2 Answers

0 votes
by
 
Best answer

Hello,
I have personally had this issue as well when using the SwitchToDialog function, sadly I am not able to look at your code but I can tell you what I did to fix it.

At first I switched to a new dialog like so:

var Core::Group homeDialog = new Application::HomeScreen;

//Dismiss current screen, switch to "home screen" 
SwitchToDialog(homeDialog , null, null, null, null, null, null, null, null, null, false);

However, I found that switching dialogs made my device hardfault or "freeze" after a few times. I suppose it has to do with the fact that I'm constantly creating a completely new dialog in memory, but switching dialogs does not actually seem to "delete" the old dialog that is dismissed when calling SwitchToDialog. Hence why switching back a few times between dialogs seems to eat your device's memory; especially with more intensive dialogs. 

The fix here is to *only* create a new dialog if it does not already exist within the application. My implementation of that is like so:

var Core::Group homeDialog = rootthis.FindDialogByClass(Application::HomeScreen);

if (homeDialog == null)
{
  homeDialog = new Application::HomeScreen;
}

Owner.SwitchToDialog(homeDialog , null, null, null, null, null, null, null, null, null, false);

Hope it helps!


 

by

Hello Tinus,

I suppose it has to do with the fact that I'm constantly creating a completely new dialog in memory, but switching dialogs does not actually seem to "delete" the old dialog that is dismissed when calling SwitchToDialog. Hence why switching back a few times between dialogs seems to eat your device's memory; especially with more intensive dialogs. 

Very interesting aspect. In fact dialogs (similar to any other dynamically allocated resource) are released automatically when they are not in use anymore. You don't need to worry about it. However, if your implementation retains a reference to the dialog, it will remain in memory. I would recommend to review your code. In case of the 'out of memory' error, you will get an error message on the console (standard out).

A hint: using the Memory (RAM) usage window, you can observe whether the number of dialog instances increases or not just at the prototyping time.

Best regards

Paul Banach

by

Hi Paul,

I think I see now what I was doing wrong before:

SwitchToDialog(homeDialog , null, null, null, null, null, null, null, null, null, false);

Here I call SwitchToDialog in the context of the presented dialog which indeed does not seem to dismiss the actual dialog. My previous fix only worked because I added owner. in front of SwitchToDialog.

Thanks for sharing your insights.

Kind regards,
Tinus
 

by
It works and I see EwObjectsMemory, it doesn't increase.
+2 votes
by

Hello Nakornthree,

First let me ask you whether there any error messages reported on the console (standard output) indicating the error source?

Nevertheless, I suppose three possible causes:

1. race conditions. Here please see the section Identify the active Dialogs and avoid race conditions. According to the description found in this chapter you can use an if-condition to check whether the component is still a dialog.

2. Multi-Tasking or interrupts. In your description you mention GPIO triggered events. Here it is important to ensure that EW code (e.g. triggering a System Event) is executed ONLY in context of the task/thread driving the GUI application. Similarly invoking some EW code from an interrupt service routine will have fatal effect. Please see the section Take care in multi-threading environments

I suppose it has to do with the fact that I'm constantly creating a completely new dialog in memory, but switching dialogs does not actually seem to "delete" the old dialog that is dismissed when calling SwitchToDialog. Hence why switching back a few times between dialogs seems to eat your device's memory; especially with more intensive dialogs. 

Very interesting aspect. In fact dialogs (similar to any other dynamically allocated resource) are released automatically when they are not in use anymore. You don't need to worry about it. However, if your implementation retains a reference to the dialog, it will remain in memory. I would recommend to review your code. In case of the 'out of memory' error, you will get an error message on the console (standard out).

A hint: using the Memory (RAM) usage window, you can observe whether the number of dialog instances increases or not just at the prototyping time.

3. Other idea: the method SwitchToDialog() is invoked in different context. This is in fact a common error source. For example, if you invoke SwitchToDialog() in context of the actually presented dialog, then it will NOT HAVE the effect of dismissing the actual dialog and replacing it by another one. Instead it will present the new dialog INSIDE the actual dialog. After some time you will have a long chain of nested dialogs occupying the RAM.

If the code invoking SwitchToDialog() does belong to the implementation of the dialog, ensure that SwitchToDialog() is invoked in context of the Owner of the dialog, for example: Owner.SwitchToDialog( newDialog, ...). See also the section The methods: PresentDialog, DismissDialog and SwitchToDialog.

I hope it helps you to narrow down the source of the problem.

Best regards

Paul Banach

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...