Main Site Documentation

EMX Strange Issue - Application gone


#1

Apologies for the uncertain title as not exactly sure what the is going on or what state they have fallen into.

Basically out at one of our client sites we have a number of EMX module applications. Every now and then we get complaints that the applications have stopped working.

When we bring them back for diagnosis it appears they have reverted to some sort of bootloader or waiting mode. They power on ok, but the application software appears not to be there and neither EMX Updater or the latest GHI Configuration Tool detects that it is connected to the computer.

But if we go through the reset process, it then detects fine, and the firmware can be reloaded, and I can re-deploy my application and it all runs fine again - so it’s not like any of the hardware has gotten damaged.

Has anybody else experienced anything like this?


#2

I think that using COM0 or mdeploy on USB would be a great help in finding what causes this issue. Using mfdeploy or terraterm will show debug information and according to what is written we will help you.


#3

Hi, thanks for the responses.

@ leforban Will try and get info via terraterm from one of the currently crashed modules. My colleague has the correct cable and software so will have to wait till he is available but will post it as soon as I can.

@ andre.m Are you suggesting that any sort of un-catched errors effectively trashes the module? I am always careful with the way I catch and deal with exceptions but I would say that unfortunately there are current issues with 4.2 in relation to networking (TCP) that are outside my control and may be generating exceptions.

I would also be very concerned that a simple un-caught error can trash the module in this way. I have watchdog enabled and it kicks in if for any reason the system hangs for a period of time - but this would be almost pointless if on reset the module cannot function and requires a complete erase and deploy.


#4

Hi Andre and Chris

I never had the issue pointed by Andre on 4.2. and according to me if it’s happenned then there’s a bug. An ucaught exception should not block the next reboot process (especially if a watchdog has been set that restart automatically the board).

Adding try catch block is good when runtime is not critical but in a lot of embedded applications we need always more and more power and as a result I put try catch only on small portion of code and as soon as possible I remove them from the code.


#5

@ andre.m Yeah I know this isn’t the greatest of threads, in some ways it does amount to “my device has stopped working”. I suppose I’m just interested in the fact that the emx module appears to be stuck in some sort of limbo state. If my application falls over and needs re-started, then that’s grand, it’s down for a period and the watchdog kicks in and it then comes back - I can look into what is taking it down. But this limbo state where it requires an erase and redeploy is not sitting well with my client.

As for exception catching, I would say I am pretty paranoid about this sort of thing and I am very confident that all my exceptions are being caught within the application. Though I can only control my own code with the libraries of Microsoft and GHI outside of that scope.


#6

Ok, took me awhile to get back on this.

Interesting update: As soon as I set LMODE from On to Off my application suddenly starting working again. That is, placing the EMX module into serial mode. And then once I switched LMODE on - placing the EMX into USB Mode, I could detect the module from my computer and the application was also fine.

So my question is, how does the switching of LMODE from On to OFF and then back ON effectively fix my issue? Note, no other updates software/ firmware or otherwise were performed.


#7

[quote]But if we go through the reset process, it then detects fine, and the firmware can be reloaded, and I can re-deploy my application and it all runs fine again - so it’s not like any of the hardware has gotten damaged.
[/quote]

What is the “reset process”?

Also, LMODE pin is only sampled on power up. The scenario above seems impossible. Is you device battery operated?


#8

Hi Gus,

The reset process is basically going through the steps as detailed in the GHI Updater Tool i.e. setting the pins, resetting the device, and then re-loading the GHI firmware, and then finally deploying are application again.

But currently we don’t need to do this anymore, as the steps now are:

  1. Power off the device.

  2. Switch LMode to Off.

  3. Power on the Device - at this stage the application software loads as normal and we are good to go again.

  4. Power off device, turn LMode On again, Power on device and we are back to the state the device was operating in while out at the client site.

But without this change in LMode from On to Off, it didn’t matter how many times the device was powered on or off again, the application would fail to start up and plugging the device into the pc via usb it would not be detected.


#9

now I remembered! This VERY unusual behavior was reported long time ago by a different customer but that was on an old firmware. He is using the latest without any problems.

Are you using the latest 4.2 firmware?


#10

The applications out on the client site are currently running 4.1. From next week we are hoping to start moving them to 4.2. I take it there haven’t been any reports of this occurring on 4.2? Also, was the other customer running 4.1?

Thanks.


#11

issue was resolved on 4.2


#12

Thanks Gus.