Main Site Documentation

G400 unintendet reboot


#1

Hi,

we are currently in the end-phase of prototyping our product and experiencing a strange behaviour of NETMF (so i guess).

First of all: our code would be too large to give you some excerpts here but i try to explain it as detailed as i can.

While debugging, the code runs perfectly fine. We have a couple of threads running in normal operation on a G400 and the netmf backend handles all serial events correct.
One of the available UARTS handles packets from a voice recognition IC (lets call it VRIC), which then leads to a method being called, depending on the content of the package that VRIC sent.
I can promise that handling these packets is working 100% correct, the error occurs only on one special packet. The method now being called by the packet-handler does some string working and uses methods, which are used by many other different modules and work fine there.

Now comes the strange part:
When in debugging mode, the desired functionality is achieved; while when executing the same code without debugger being attached, the G400 seems to deadlock for a short duration and reboots afterwards. No exceptions, no info - just a reboot. I tried using display information to know exactly where this happens but i wasn’t able to spot the line of code. Additionally i printed all relevant data manually on our display and verified its correctness too.
I think it has something to do with threading and the fact that the debugger mode slows things so much down that it distorts the desired behaviour.

Now i have some questions, which might clear up this topic for me:

  1. Are SerialRecievedCallbacks of different interfaces of the same type (COM1, COM2, COM3, …) blocking towards each other ?
  2. Which options do i have as managed apllication developer to obtain hardware level exeptions or stackdumps of the cpu ?
  3. Have locks ever worked on netmf ?

If you could provide me some information or some hints it would be nice.
Thanks in advance.


#2
  1. Any event blocks other events
  2. Some chips have a register that give you the rest reason, like was it watchdog?
  3. Locks should work

When the application seem to pause, can you ping it from mfdeploy? You can also switch to serial debugging instead of USB. This will give you more info around rest since USB is not always ready.

Can you keep a thread with a clubbing led to see if the led works when you think the application has paused.


#3

Thank you !!
With the help of MSDeploy i was able to figure out a major synchronization problem, which led to this issue.