G120 COM1 Exceptions

NETMF & Gadgeteer
1

G120 Firmware 4.2.7.0

I am getting these exceptions streaming in through COM1, even though I am using USB debugging. I am testing the new serial multiplexer I designed, and this involves a lot of consecutive reads and writes on all 5 serial ports. This exception occurs fairly consistently during each test run (about 4 minutes in), which leads me to believe that it may be memory related.

Before I start poking around and doing due-diligence, does anyone know what they are, at first glance? They seem to be blowing right past the VS2010 debugger (when this occurs, the G120 simply locks up, and no exceptions are returned to Visual Studio).

EXCEPTION 0x06:
cpsr=0x00000001
pc =0x00000000
lr =0x00020001
sp =0x10002068
r00 =0x10002028
r01 =0x00000000
r02 =0x00000001
r03 =0x00001000
r04 =0x1000f7c0
r05 =0x00020001
r06 =0x00000000
r07 =0x00000001
r08 =0x00000000
r09 =0xa001dc58
r10 =0x1000fba0
r11 =0x1000fb98
r12 =0x1000f7c0
EXCEPTION 0x06:
cpsr=0x00000001
pc =0x00000000
lr =0x00020001
sp =0x10002048
r00 =0x10002008
r01 =0x00000000
r02 =0x00000001
r03 =0x00001000
r04 =0x1000f7c0
r05 =0x00020001
r06 =0x00000000
r07 =0x00000001
r08 =0x00000000
r09 =0xa001dc58
r10 =0x1000fba0
r11 =0x1000fb98
r12 =0x1000f7c0
EXCEPTION 0x06:
cpsr=0x00000001
pc =0x00000000
lr =0x00020001
sp =0x10002028
r00 =0x10001fe8
r01 =0x00000000
r02 =0x00000001
r03 =0x00001000
r04 =0x1000f7c0
r05 =0x00020001
r06 =0x00000000
r07 =0x00000001
r08 =0x00000000
r09 =0xa001dc58
r10 =0x1000fba0
r11 =0x1000fb98
r12 =0x1000f7c0

2

This will have ot be fixed on our end.

Can you please tell us what we need ot do to repro this?

3

Sure. Let me get to the root culprit, then I will let you know how to reproduce. Thanks!

4

Having the same issue once in a while…


using System.Diagnostics;
using System.IO.Ports;
using Microsoft.SPOT;

namespace SenticsLib
{
    public static class DebugHelper
    {
        private static bool _outputModeRs232;
        private static SerialPort _serialPort;

        [Conditional("DEBUG")]
        public static void DebugPrint(string msg)
        {
            if (!_outputModeRs232)
                Debug.Print(msg);
            else
            {
                var buffer = new byte[msg.Length + 2];
                for (int i = 0; i < msg.Length; i++)
                {
                    buffer[i] = (byte) msg[i];
                }
                buffer[buffer.Length - 2] = 0xA;
                buffer[buffer.Length - 1] = 0xD;
                _serialPort.Write(buffer, 0, buffer.Length);
            }
        }

        [Conditional("DEBUG")]
        public static void UseRs232()
        {
            _outputModeRs232 = true;
            _serialPort = new SerialPort("COM1", 115200);
            _serialPort.Open();
        }
    }
}
5

I have narrowed the offending code to the following barebones representation. I can consistently reproduce the crash on my Cobra II, firmware 4.2.7.0.


// Required assembly references:
// GHI.Premium.Hardware.G120
// Microsoft.SPOT.Hardware
// Microsoft.SPOT.Native
// mscorlib

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHI.Premium.Hardware;

namespace G120_Freezes
{

    public class Program
    {
        // The contents of this array are not important. It's the allocated size that matters.
        // Larger sizes make the G120 freeze sooner.
        // With 2000 elements, the processor freezes at ~3350 cycles.
        public static byte[] someArray = new byte[2000];

        public static void Main()
        {
            // Lets us know if the board has frozen, in addition to the Debug.Print() output
            BlinkThread.Start(); 

            // Running this secondary thread is required for the freeze to occur.
            // If you comment out the line below to prevent the 2nd thread from running, the freeze will NOT occur. 
            // Instead, the garbage collector will kick in at exactly the same moment the processor would have 
            // frozen otherwise.
            AnotherThread.Start(); 

            int cycleCount = 1;
            while (true)
            {              
                Utility.ExtractRangeFromArray(someArray, 0, someArray.Length);
                Debug.Print(cycleCount.ToString());
                cycleCount += 1;
            }
        }

        public static ManualResetEvent MyWaitHandle = new ManualResetEvent(false);
        public static Thread AnotherThread = new Thread(new ThreadStart(AnotherMethod));
        public static void AnotherMethod()
        {
            while (true)
            {
                MyWaitHandle.WaitOne(600, false);
                MyWaitHandle.Reset();
            }
        }

        // Blink routine informs us if the Cobra II has frozen, in case we aren't looking at the
        // Debug.Print() output.
        private static Thread BlinkThread = new Thread(new ThreadStart(BlinkRoutine));
        private static void BlinkRoutine()
        {
            OutputPort LED = new OutputPort((Cpu.Pin)G120.Pin.P1_15, true);
            while (true)
            {
                Thread.Sleep(250);
                LED.Write(false);
                Thread.Sleep(250);
                LED.Write(true);
            }
        }
   
    }
}
6

Have your tried the 4.2.8 Beta?

7

Not yet. I think the link got removed before I could get to it.

@ Robvan - If you have a Cobra II, perhaps you can try to run my code with the beta firmware? I’m curious to see if the problem is there, too.

8

@ Iggmoe - I have a custom board with G120 with MF 4.2.8 Beta… Just tested your code and it keeps running… i watched for about a 150.000 cycles

9

@ Iggmoe - After testing your code i deployed my own code back. After a hard reset i have the same kind of exception message as you showed. The only way to solve this is to flash the firmware.

10

@ RobvanSchelven - Could you post the code that you are using after you deploy Iggmoe’s code?

11

@ Steven - Have you been able to reproduce the issue with my code?

12

@ Steven - I could email you the solutions that consist of my code… After i tested Iggmoe’s code, i deployed my own code and did a hard reset to the board… For debugging purposes i have Com1 of the G120 always connected to my desktop so i was notified by the low level MCU exceptions. I did not pay much attention to it because i have seen this expectations many times, knowing GHI is working on the low level code. I erased and flashed the device and used MFDeploy to see if it was working. I switched the board off and decided to deploy the managed code later today because i was also working on it.

After your question from half an hour ago i decided to switch the board on and to deploy the code… But for some reason i am not able to run it or reach Main() when starting a debug session… I repeated to flash the firmware again, but same results… Since my last successful deploy of 2 days ago my code has been changed… mainly added Encryption functionality… Let me find out why the code won’t reach main before i send you one and another

Found debugger!

Create TS.

Loading start at a0e00000, end a0e0fc38

Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Hardware (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Loading Deployment Assemblies.

Attaching deployed file.

Assembly: MFClassLibrary (1.0.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Hardware.OneWire (4.2.0.0) Attaching deployed file.

Assembly: GHI.Premium.IO (4.2.8.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.IO (4.2.0.0) Attaching deployed file.

Assembly: GHI.Premium.System (4.2.8.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Security.PKCS11 (4.2.0.0) Attaching deployed file.

Assembly: System (4.2.0.0) Attaching deployed file.

Assembly: BedApplication (1.0.0.0) Attaching deployed file.

Assembly: GHI.Premium.Net (4.2.8.0) Attaching deployed file.

Assembly: System.IO (4.2.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Net (4.2.0.0) Attaching deployed file.

Assembly: System.Security (4.2.0.0) Attaching deployed file.

Assembly: GHI.Premium.Hardware (4.2.8.0) Attaching deployed file.

Assembly: GHI.Premium.Native (4.2.8.0) Attaching deployed file.

Assembly: GHI.Premium.Hardware.G120 (4.2.8.0) Resolving.

GC: 1msec 463644 bytes used, 6876024 bytes available

Type 0F (STRING ): 24 bytes

Type 15 (FREEBLOCK ): 6876024 bytes

Type 17 (ASSEMBLY ): 24636 bytes

Type 1E (BINARY_BLOB_HEAD ): 438912 bytes

Type 34 (APPDOMAIN_HEAD ): 72 bytes

GC: performing heap compaction…

The debugging target runtime is loading the application assemblies and starting execution.
Ready.

13

I just want to add that this is a critical issue for a soon-to-be-released product, so any information on when a fix might be available, or at the very least a suitable workaround, would be appreciated. The serial multiplexer has to work for many hours without locking up. Thank you.

14

@ Steven - To follow up on my last message… The generation of MCU exceptions after deploying my “old” code has to do with new functionality that i added to my code over the last days. I created a new topic about that issue at http://www.tinyclr.com/forum/topic?id=10816

15

Firmware 4.2.9.0 seems to have fixed the issue. Thanks GHI!

16

Excellent, thanks for the confirmation