After a long period of issues with the G120 i had to deliver the first systems to my client. The first system returned after 3 days and was just outputting low level exception info to com1. 
Flashing the device is the only way to get it back running.
@ GHI please help… this will destroy my business.
EXCEPTION 0x03:
cpsr=0x21000000
pc =0x0000ae78
lr =0x0000ae75
sp =0x1000fec8
r00 =0x00000000
r01 =0x00000061
r02 =0x0000001a
r03 =0x1000fea6
r04 =0xaff8ff90
r05 =0xf03fff90
r06 =0xa0370000
r07 =0x1000ff18
r08 =0xa037ff90
r09 =0xa037ff90
r10 =0xa0000508
r11 =0x00000128
r12 =0xa0000824
EXCEPTION 0x03:
cpsr=0x1000ff18
pc =0xa0370000
lr =0xf03fff90
sp =0x1000fea8
r00 =0x00000001
r01 =0x00000001
r02 =0x00000001
r03 =0x00001000
r04 =0xaff8ff90
r05 =0xf03fff90
r06 =0xa0370000
r07 =0x1000ff18
r08 =0xa037ff90
r09 =0xa037ff90
r10 =0xa0000508
r11 =0x00000128
r12 =0xaff8ff90
EXCEPTION 0x03:
cpsr=0x1000ff18
pc =0xa0370000
lr =0xf03fff90
sp =0x1000fe88
r00 =0x00000001
r01 =0x00000001
r02 =0x00000001
r03 =0x00001000
r04 =0xaff8ff90
r05 =0xf03fff90
r06 =0xa0370000
r07 =0x1000ff18
r08 =0xa037ff90
r09 =0xa037ff90
r10 =0xa0000508
r11 =0x00000128
r12 =0xaff8ff90
We understand the urgency of this.
Does your device use networking?
Yes its using the network over WiFi (RS9110)
Are you able to reproduce the error again?
@ Gus - Not sure yet. It feels like it happens randomly. The application keeps a log file on SD card and for now i can see that send date over OneWire failed after 3 retries. This was the last registered action.
It must be the flash that gets corrupted for what ever reason… From a hardware perspective to protect the device for write errors during power cycles we have a MAX811-EUS-T supervisory circuits in the design.
Last week i removed all EWR related stuff from code to reduce the write to config flash.
If you get this to happen aging, can you try to only load the config file using mfdeploy? Not the firmware, just the config file.
@ Gus - It happens again today (low level exception 3)… and as proposed i re-flashed config.hex only, using mfdeploy. This brought the device back to live… Its obvious that write actions to flash are the source of the problem.
The question however is, is it hard or software related. If its software related and as a work around for now, how to reduce the number of write actions to flash from managed code (if possible)
Maybe important to note again from another thread… (since it was unanswered) a call to _wifi.NetworkInterface.EnableStaticIP(…) always changes the CRC code of config memory, even if the parameters are the same as used before…
Q. is this by design or can it be considered as a bug?
This is what I suspected. This isa tough software bug but we are determined to find it and squish it.
I highly doubt it. This is a timing issue with software working with Hardware.
We re you able to reproduce the problem again?
@ Gus - No, It did not appeared today…
We may have something but I am afraid we do not know for sure as we are not seeing the problem wither way!
I am happy to test it out if possible…
What keeps me thinking today was what voltage tolerance is acceptable for the G120 module… Is it 5%
@ Gus - How to proceed? Is there something you can email me to test?
You do not see the problem on existing firmware so anything further can only cause confusion.
We are still testing on our end.
@ Gus - I think i am blond today 
i do not fully understand your first sentence but your last sentence is clear…
@ Gus - [quote]We may have something but I am afraid we do not know for sure[/quote]
Is there any technical background information you can share?
Flashing the device is the only way to get it back running.
i do not fully understand your first sentence but your last sentence is clear…