G400 spontaneously resets itself

Sergey_Bokhantsev · January 13, 2015, 9:20am

Relating to device hangs, here is another story. May be it will helpful for someone.

I also had periodic hangs and resets of my Raptor. And for last few month without no luck to fight its.

But the reason in my case was related to incorrect connecting of Raptor board to Arduino via UART.

My boards is powered by one collective 9V supply unit (connected in parallel to both boards power input connectors).
So I mistakenly thought that this scheme is ok because boards Grounds are coupled.

But it is need to connect both board Grounds one more time somewhere after each board power converter.

After I did this extra wiring, hangs were gone

mhstr · February 3, 2015, 2:40pm

I have maybe similar problem with my Raptor and GSM modem connected but I do not understand why there could be a probem with ground becuase if devices(Raptor and GSM modem are powered also by separate power supplies) are connected through RS232 then one of the RS232 pin(pin 5) is GND so GND are interconnected anyway am I right?
Or there must be special GND interconnection even though GNDs are interconnected by RS232?

I am already quite frustrated by this random hangs and restarts becuase there is no relevant reasons in DEBUG(I use COM1 as debug) output - no exceptions etc.
It just hangs (without possibility to connect FEZ Config to TinyCLR) or sometimes restarts so I really do not know what should I looking for - if this is application software problem or possible Raptor HW problem or…

I am guessing if it was application software problem then there should be some exception etc.My application uses three RS232 connection each handled in separate task.

Thanks for any suggestion.

Brett · February 3, 2015, 2:58pm

well depending on the RS232 adapters you’re using, there’s a chance things aren’t as clear as “GNDs connected”. But ordinarily you would expect them to but it’s a dead easy thing to test with a multimeter.

Sergey_Bokhantsev · February 3, 2015, 4:32pm

@ mhstr - does it hangs with GSM module disconnected?

Also I remember that in my case I’ve found a stable way to get it hang: when I touching Raptor ground somewhere on board with a multimeter’s probe then it just hangs right away.
After I connected both boards GNDs this behavior was gone.

mhstr · February 4, 2015, 3:12pm

I have measured GNDs connection and it seems OK, there is no difference between Raptor and connected modem.
Also multimeter’s probe doesn’t generate any reset or hangs when touching Raptor.

But I have used my second(and last) Raptor board to test the same application and it seems that this board behaves much better. The application was running almost 12 hours without any problems. After this there was generated some Uncaught exception:

Exception System.Exception - CLR_E_WRONG_TYPE (8)

#### Message: 
#### System.Text.UTF8Encoding::GetChars [IP: 0000] ####

when reading/decoding GSM modem response. But this is maybe another story even though I am not sure why there is this exception after such a long time because the application reads the same data periodically all the time.
But maybe if this exception was handled in application(and it probably should be) then it would run OK until now I am guessing.

So right now I will continue with that(seems) “better” Raptor but to be honest it is like a magic because I do not know why the same HWs behave differently and we are going to start serial production…

By the way I am using the latest Firmware(4.3.6.0) and TinyBooter(4.3.6.0)

Brett · February 4, 2015, 3:14pm

that UTF character conversion issue to me smells like bad data. Please explain how this modem is connected to your Raptor. You mentioned RS232? Please explain…

mhstr · February 4, 2015, 4:54pm

Yes, GSM modem is connected to Raptor through RS232(Rx, Tx, GND) - COM2(X4 socket) right now 9600Bd.
Maybe some data were somehow corrupted on this serial line during reading.

Brett · February 4, 2015, 5:27pm

Sorry do you REALLY mean RS232? You have an RS232 module (or a MAX2232 or similar chip) between the Raptor and the modem ? Or do you just mean UART that runs at TTL signal level… and either way, how long are your cables ? pictures might help.

leforban · February 5, 2015, 5:17am

If it’s an UART that runs at TTL level, this might create issues IOpins of G400 are 3.3V compliant, not 5V

mhstr · February 5, 2015, 4:29pm

No. We use standard RS232 module from GHI connected to the one Raptor socket. So the COM port levels should be absolutely correct. The cables are max. 2 meters. I have also tried to power Raptor from external power supply.

We use actually 3 sockets because we use three COM ports:

one for communication to GSM modem(one thread)
one for communication with PC(second thread)
one for communication with some intelligent probe(third thread)

And additionally:

also I2C(HW not SW implementation) for communication with I/O expanders(fourth thread)
signalling LED fifth thread

But today also failed my second Raptor(mentioned as better Raptor). It was even I have simplified my application for this test where only GSM and LED threads were activated.

There was one total restart after cca. 5 hours and then after next 2 hours the Raptor hanged without any generated exception - just hanged without possibility to connect FEZConfig so TinyCLR also didn’t work.

It is strange that almost always some seconds before reset the COM to GSM cannot receive any data(from my debug output).
But on the other hand there is nothing special before hang.

I am also calling periodically GC every cca. 15sec. to avoid situation when GC is executed during serial transactions because especially PC communication protocol which is used here is sensitive to longer gaps. But it should be safe to call GC explicitly as it was also mentioned somewhere in the different forum thread. And it also helps to see memory consumption - here is also nothing strange there is no memory leak when application runs.
I have also changed serial communication driver from event driven RX to periodical checking to try different approach and the result is the same. Driver is also part of this post(the low level part for reception).

========================================================
From my DEBUG output(COM1):

stringToSend: AT+CREG?

responseTimeout: 500
maxTimeoutBetweenCharacters: 100
numOfReceivedBytes: 20
receivedString:
+CREG: 0,1

OK

GC: 2msec 448980 bytes used, 66656784 bytes available
Type 0F (STRING ): 7728 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656784 bytes
Type 17 (ASSEMBLY ): 38004 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 648 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343248 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 11465
time (%5): 02/05/2015 11:13:02
stringToSend: AT+CREG?

responseTimeout: 500
RomBOOT

G400
Version: 4.3.6.0
Debug: COM1
LCD: 0x0
úG400
Version: 4.3.6.0
Debug: COM1
LCD: 0x0
.NetMF v4.3.1.0
G400, Build Date:
Oct 21 2014 13:05:29
ARM Compiler version 410713

TinyCLR (Build 4.3.1.0)

=======================================================
COM port driver without Tx event routine:

 receivedBytes)
    {
      numOfReceivedBytes = 0;
      if (bytesToSend.Length > 0)
      {
        Send(bytesToSend); // opens port and send data
      }

      Open(); // checks if port has been already opened and if not opens it

      // check first received character = response timeout
      MyDebug.PrintUnconditional("  <SendWaitResp> responseTimeout: " + responseTimeout.ToString());
      int i = responseTimeout/10;
      if (i < 1) 
        i = 1;
      while (i > 0)
      {
        Thread.Sleep(10);
        if (serialPort.BytesToRead > 0)
          break;
        else
          i--;
      }

      if (i <= 0)
      {
        // response timeout occured
        if (serialPort.IsOpen)
        {
          serialPort.Close();
        }
        return (0);
      }

      // receive data until "inter characters" timeout occures
      MyDebug.PrintUnconditional("  <SendWaitResp> maxTimeoutBetweenCharacters: " + maxTimeoutBetweenCharacters.ToString());
      int tmout_ticks = maxTimeoutBetweenCharacters / 10;
      if (tmout_ticks < 1)
        tmout_ticks = 1;

      int j = tmout_ticks;
      while (j > 0)
      {
        Thread.Sleep(10);
        int bytesLength = serialPort.BytesToRead;
        if (bytesLength > 0)
        {
          serialPort.Read(_rxCatchBuffer, numOfReceivedBytes, bytesLength);
          numOfReceivedBytes += bytesLength;
          j = tmout_ticks;
        }
        else
        {
          j--;
        }
      }
      receivedBytes = _rxCatchBuffer;


      MyDebug.PrintUnconditional("  <SendWaitResp> numOfReceivedBytes: " + numOfReceivedBytes.ToString());
      if (serialPort.IsOpen)
      {
        serialPort.Close();
      }
      return (numOfReceivedBytes);
    }

Brett · February 5, 2015, 6:38pm

so if I read your debugging correctly, it seems that GC kicks in and then you have trouble reading stuff. I’d be looking for whatever GC is cleaning up - the COM port going out of scope perhaps ?

mhstr · February 6, 2015, 3:45am

This is not like that that communication stuff is somehow corrupted immediately when GC is executed but it looks like that from my debug snippet because I have copied right communication transaction sequence

stringToSend: AT+CREG?

responseTimeout: 500
maxTimeoutBetweenCharacters: 100
numOfReceivedBytes: 20
receivedString:
+CREG: 0,1

OK

immediately before GC stuff to see the difference.

Here is whole problematic sequence:

From my DEBUG output(COM1):

stringToSend: AT+CREG?

responseTimeout: 500
maxTimeoutBetweenCharacters: 100
numOfReceivedBytes: 20
receivedString:
+CREG: 0,1

OK

stringToSend: AT+CMGL=“ALL”

responseTimeout: 2000
maxTimeoutBetweenCharacters: 500
numOfReceivedBytes: 6
receivedString:
OK

stringToSend: AT+CLCC

responseTimeout: 5000
maxTimeoutBetweenCharacters: 500
numOfReceivedBytes: 6
receivedString:
OK

GC: 2msec 448980 bytes used, 66656784 bytes available
Type 0F (STRING ): 7728 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656784 bytes
Type 17 (ASSEMBLY ): 38004 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 648 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343248 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 11450
time (%5): 02/05/2015 11:12:51
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
GC: 2msec 448980 bytes used, 66656784 bytes available
Type 0F (STRING ): 7728 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656784 bytes
Type 17 (ASSEMBLY ): 38004 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 648 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343248 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 11455
time (%5): 02/05/2015 11:12:54
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
GC: 2msec 448980 bytes used, 66656784 bytes available
Type 0F (STRING ): 7728 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656784 bytes
Type 17 (ASSEMBLY ): 38004 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 648 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343248 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 11460
time (%5): 02/05/2015 11:12:58
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
GC: 2msec 448980 bytes used, 66656784 bytes available
Type 0F (STRING ): 7728 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656784 bytes
Type 17 (ASSEMBLY ): 38004 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 648 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343248 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 11465
time (%5): 02/05/2015 11:13:02
stringToSend: AT+CREG?

responseTimeout: 500
RomBOOT

G400
Version: 4.3.6.0
Debug: COM1
LCD: 0x0
úG400
Version: 4.3.6.0
Debug: COM1
LCD: 0x0
.NetMF v4.3.1.0
G400, Build Date:
Oct 21 2014 13:05:29
ARM Compiler version 410713

TinyCLR (Build 4.3.1.0)

Starting…
Created EE.
Started Hardware.
MSdbgV1 •…ó
"p đ› Create TS.
Loading start at 202d8818, end 20307cac
Assembly: mscorlib (4.3.1.0) Assembly: Microsoft.SPOT.Native (4.3.1.0) Assembly: Microsoft.SPOT.Security.PKCS11 (4.3.1.0) Assembly: System.Security (4.3.1.0) Assembly: Microsoft.SPOT.Hardware (4.3.1.0) Assembly: Microsoft.SPOT.Graphics (4.3.1.0) Assembly: Microsoft.SPOT.TinyCore (4.3.1.0) Assembly: Microsoft.SPOT.IO (4.3.1.0) Assembly: System.IO (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.Usb (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.SerialPort (4.3.1.0) Assembly: Microsoft.SPOT.Touch (4.3.1.0) Assembly: Microsoft.SPOT.Ink (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.PWM (4.3.1.0) Loading Deployment Assemblies.

Brett · February 6, 2015, 4:59pm

Two thing I still am not clear on.

First, it still looks to me like a GC fires and then responses from the modem fail. I’d still be looking for something that GC is cleaning up and causing an impact on. To further eliminate the modem and cable from any impact, can you “fake” responses from the modem to your control inputs on a PC? That will tell you two things - first, if the parts where the request is being sent the data is actually being transmitted, and second if you guarantee the response is being sent from the PC but the handler doesn’t see the data you can tell again the UART is somehow messed up

Second, are you using watchdog timer at all ?

mhstr · February 6, 2015, 5:15pm

No I don’t use WatchDog.
In future I am planning to use WatchDog but according my opinion this is a last step.
It doesn’t have any sense to activate WatchDog if application is not able to run e.g. 1 day without reset/hang. First the problem must be solved and then it is time to activate WatchDog as a backup.

I can try to simulate modem responses but it will take some time.

Regarding GC I am not sure if GC causes this problem because according debug messages there is no response even some time before GC is fired so I am not sure.

Brett · February 6, 2015, 6:07pm

Sorry, le me be explicit here. Here is where I think GC kicks your butt. This is from your earlier post, what am I misinterpreting here that implies it is not GC?

[quote] stringToSend: AT+CMGL=“ALL”

responseTimeout: 2000
maxTimeoutBetweenCharacters: 500
numOfReceivedBytes: 6
receivedString:
OK

stringToSend: AT+CLCC

responseTimeout: 5000
maxTimeoutBetweenCharacters: 500
numOfReceivedBytes: 6
receivedString:
OK

<< Brett: Still all working OK at this point, yeah? the OK response is good. >>

GC: 2msec 448980 bytes used, 66656784 bytes available
Type 0F (STRING ): 7728 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656784 bytes
Type 17 (ASSEMBLY ): 38004 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 648 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343248 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…

<< Brett: GC has now run. Next response fails. >>

stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?
[/quote]

I ask about watchdog because I wondered if that was doing the reset for you. I agree with you that watchdog is sometimes a crutch people use for when their code doesn’t work properly, so don’t recommend you play with it in these situations as that will only make things more complex not less.

mhstr · February 7, 2015, 4:43am

@ Brett -
Thanks for your investigation.
It is not always like that that reception stops immediately after GC as shown in the following debug snippet:

stringToSend: AT+CLCC

responseTimeout: 5000
maxTimeoutBetweenCharacters: 500
numOfReceivedBytes: 6
receivedString:
OK

GC: 2msec 449340 bytes used, 66656424 bytes available
Type 0F (STRING ): 7896 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656424 bytes
Type 17 (ASSEMBLY ): 38028 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 864 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343200 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
maxTimeoutBetweenCharacters: 100
numOfReceivedBytes: 20
receivedString:
+CREG: 0,1

OK

stringToSend: AT+CMGL=“ALL”

responseTimeout: 2000
maxTimeoutBetweenCharacters: 500
numOfReceivedBytes: 6
receivedString:
OK

stringToSend: AT+CLCC

responseTimeout: 5000
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 7790
time (%5): 02/02/2015 09:12:29
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
GC: 2msec 449340 bytes used, 66656424 bytes available
Type 0F (STRING ): 7896 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656424 bytes
Type 17 (ASSEMBLY ): 38028 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 864 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343200 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
gsmTaskState (%5): 2
debugCounter (%5): 7795
time (%5): 02/02/2015 09:12:33
stringToSend: AT+CREG?

responseTimeout: 500
receivedString:
GC: 2msec 449340 bytes used, 66656424 bytes available
Type 0F (STRING ): 7896 bytes
Type 11 (CLASS ): 33276 bytes
Type 12 (VALUETYPE ): 3144 bytes
Type 13 (SZARRAY ): 11280 bytes
Type 01 (BOOLEAN ): 24 bytes
Type 03 (U1 ): 3060 bytes
Type 04 (CHAR ): 1032 bytes
Type 07 (I4 ): 1716 bytes
Type 0F (STRING ): 648 bytes
Type 11 (CLASS ): 4800 bytes
Type 15 (FREEBLOCK ): 66656424 bytes
Type 17 (ASSEMBLY ): 38028 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 168 bytes
Type 1B (DELEGATE_HEAD ): 864 bytes
Type 1D (OBJECT_TO_EVENT ): 552 bytes
Type 1E (BINARY_BLOB_HEAD ): 343200 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 2244 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 27 (FINALIZER_HEAD ): 408 bytes
Type 31 (IO_PORT ): 396 bytes
Type 33 (I2C_XACTION ): 48 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4476 bytes
GC: performing heap compaction…
RomBOOT

G400
Version: 4.3.6.0
Debug: COM1
LCD: 0x0
úG400
Version: 4.3.6.0
Debug: COM1
LCD: 0x0
.NetMF v4.3.1.0
G400, Build Date:
Oct 21 2014 13:05:29
ARM Compiler version 410713

TinyCLR (Build 4.3.1.0)

Dat_Tran · February 9, 2015, 9:39am

@ mhstr -

we sent you a test version last week, have you tried it yet, please?

mhstr · February 9, 2015, 3:27pm

@ Dat - Thanks for this. I will try it as soon as possible.

Meanwhile I have tried the following with interesting result:

There is also I2C task in this project which reads/write from/to I2C I/O expanders regularly each 100msec. I have commented out this task just to see difference. I use some I2CBus class(FusionWare.SPOT.Hardware namespace) library which somehow encapsulates standard hw I2C implementation.
I have disabled explicit calling of GC(so GC is called automatically now)
I have compiled application as a RELEASE.

The application was running almost 2 days without any problem and after this time there was one reset(unfortunately again without any reported exception reported in DEBUG-COM1 before reset).

So I have a suspicion I2C task can cause some troubles but not sure.

G400 spontaneously resets itself

Exception System.Exception - CLR_E_WRONG_TYPE (8)

======================================================== From my DEBUG output(COM1):

TinyCLR (Build 4.3.1.0)

======================================================= COM port driver without Tx event routine:

Here is whole problematic sequence:

From my DEBUG output(COM1):

========================================================
From my DEBUG output(COM1):

=======================================================
COM port driver without Tx event routine: