12 replies to this topic

[GDSever]

I have an issue that is difficult to track down. My project seems to run fine for several minutes (sometimes as many as 20), but at some point the device resets / reboots - and it seems to happen randomly.

 

Here's a brief description of the hardware setup:

 

• Netduino 1 running 4.2 firmware & framework
• Sparkfun XBee shield with a Series 2 Xbee running coordinator firmware
• I2C connection to a MCP23017, a MCP23008, and a 24LC256
• Interrupt from MCP23017 connected to D2

 

One thing I have noticed is that right before the Netduino resets there is a flurry of DOUT LED activity on the Xbee shield. Immediately following this the blue LED on the Netduino board flashes on, then off, and the device resets. Aside from the visual clues I described, the connected MCP23008 is driving a 20x4 LCD screen, so I also get that visual clue that the device reset.

 

I am not attempting to reset anything from either the hardware or code, and I have tried both USB and external power supplies, so I don't think it is a "brownout" condition.

 

• What are the conditions that would cause a Netduino 1 to reset itself, particularly that might be tied to the DOUT LED on the Xbee shield, if any? 
• If you were trying to diagnose a seemingly random reboot issue that occurs many minutes apart, what else might you try?

 

Best regards,

-Garrett

[wendo]

How are you powering this?

[Chris Walker]

Hi Garrett, If the board is rebooting, it's most likely that it's either a big surge in power by one of your components (which causes the brownout reset) or something is asserting the /RESET pin on your Netduino mainboard. Chris

[GDSever]

If the board is rebooting, it's most likely that it's either a big surge in power by one of your components (which causes the brownout reset) or something is asserting the /RESET pin on your Netduino mainboard.

 

I have been powering the circuit by both the USB cable and a breadboard power supply from Sparkfun. In both cases the reboots occur, and I assumed the breadboard power supply would have more than enough juice to power things. To the best of my knowledge nothing is connected to the /RESET pin directly, unless the XBee shield is doing something it shouldn't. 

 

Thank you for the insight. I will continue to look at the power to see if that is the issue. In the meantime, could any of the following cause a reboot on a Netduino 1?

 

• Collisions accessing variables / values between different threads?
• Using up the available flash memory either through bad coding or bad garbage collection?
• I2C Device collisions (although I am using the FusionWare I2CBus class)?

 

At this point I can't rule out software issues vs. hardware issues... but I don't know the Netduino platform well enough to say whether any of the above could cause a reboot.

 

I am also still trying to understand why the DOUT light goes nuts right before the reboot. I can't figure out why that would happen.

 

Best regards,

[Chris Walker]

Hi Garrett, Software issue is theoretically possible, but pretty unlikely. Can you add some Debug.Print statements to your code (around a few different sections) to try to narrow down where the reset is happening? Also...check the shield schematics and see if /RESET is connected to it. Finally...if there's a software-caused short circuit happening somewhere, that could also cause a reset. Chris

[GDSever]

Chris, what sort of software-caused short circuit were you thinking? 

 

I have tried the debug.print statement route and couldn't locate what was going on. As I indicated, it doesn't seem to be tied to any particular action in the system - no buttons are pressed, no update to the LCD screen is occuring, nothing is being written to / from the I2C buffer.... I'll load it up with Debug.Print statements again including places I didn't try last time and see if I missed something.

 

I tied the /RESET pin to VCC, which seemed to keep it from resetting, however the device did stop responding - so even though it didn't reset, it probably wanted to at some point and couldn't.

 

I have also powered the circuit from a 1.5A 5V breadboard supply and still got the reboot - so I don't think brown-out is causing the issue.

 

Any insight you might have on the sorts of software-caused short circuits might be happening, I'd appreciate it.

 

Best regards,

-Garrett

[GDSever]

Well I think I have tracked it down to the routine that reads the bytes from the serial port. It is in that routine (or one of the resulting events) that the error seems to occur.

 

It's not clear yet whether it is an Xbee issue, a serial port issue, or a code issue. I guess I will keep digging.

[Chris Walker]

Hi Garrett, When you tied /RESET to Vdd, and the device stopped responding, did NETMF continue running on the mainboard? If so, then it's almost definitely an issue on the shield (something locking up on the shield that resets its IC which is connected to the /RESET line perhaps). Chris

[GDSever]

Hi Garrett, When you tied /RESET to Vdd, and the device stopped responding, did NETMF continue running on the mainboard? If so, then it's almost definitely an issue on the shield (something locking up on the shield that resets its IC which is connected to the /RESET line perhaps).

 

If I fail to track down the problem inside the code, I will certainly check into this. I am already thinking through how to ditch the shield and just tie COM1 to the XBee and see if that makes a difference... although I am thinking more and more that it is the ReceiveData routine in the MFToolkit class (which I translated into VB.NET, so I might have missed something critical in the process.) I have also been toying with the idea of overriding the method I translated and building an Escaped API mode routine from ground-up...

 

I will certainly let you know if I track this nasty gremlin down... or at least eliminate it by replacing the code.

[Chris Walker]

Hey Garrett, Do you have any jumper wires? You can detach the shield and just add jumper wires between the mainboard and shield...and not connect the /RESET pin. That might get you closer to resolution. Chris

[GDSever]

Well, I am not sure exactly what fixed it, but I haven't had the random reboot issue for a few days now. I put in a bunch of debug.print statements and managed to narrow it down to the thread that receives COM1 data from the XBee. I don't know if the debug.Print statements slowed things down enough that it stopped the error from occuring, or if one of my frantic coding tweaks (Like SyncLock-ing the serial port object) managed to fix it, but I'm not gonna fiddle with it more unless the problem creeps back up. Thank you all for the insight and assistance.

 

Best regards,

[GDSever]

Well my wishful thinking was just that... My random reboot issue is not gone, it's still causing me headaches.

 

I did narrow it down to the routine that reads data from the SerialPort. There is a ton of data that comes in, apparently faster than the routine can process it, and at some point during that process it causes the Netduino to reboot.

 

My question is - can overloading the SerialPort cause a hardware reset, through overflow or otherwise?

 

I still need to contact Digi support to see if they can make any sense of the byte stream that is coming in and tell me if they see any potential reason / cause why the XBees would be doing this, but I thought I could at least see if there were some programmed failsafe that causes hardware reboots for SerialPort overflows...

[GDSever]

Well, after exhausting all of my other possibilities I finally did what you suggested, Chris, back on January 21. With the shield removed and jumper wires connecting the COM1 pins and 5V/GND to the shield, the Netduino does not reset (although the huge data packet is still sent to periodically, the code handles it without reset). 

 

I still need to track down why the COM1 "dump" occurs in the first place with the DIGI folks.