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:
- Are SerialRecievedCallbacks of different interfaces of the same type (COM1, COM2, COM3, …) blocking towards each other ?
- Which options do i have as managed apllication developer to obtain hardware level exeptions or stackdumps of the cpu ?
- Have locks ever worked on netmf ?
If you could provide me some information or some hints it would be nice.
Thanks in advance.