http://forums.leaflabs.com/topic.php?id=2642 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:21:40 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=2642#post-13103 Mon, 03 Sep 2012 13:15:18 +0000 gbulmer 13103@http://forums.leaflabs.com/ <p>palsor - It sounds like a variable has been damaged. </p> <p>The throbbing LED is the LeafLabs' Maple fault handler effectively reporting that something bad went wrong. </p> <p>There are several possible causes, including: accessing an invalid memory address (pointer has been damaged), trying to read an instruction from a wrongly-aligned address or trying to read an invalid instruction (typically a return address or function pointer has been damaged).</p> <p>It is highly unlikely that the extra print statements fix anything. It is more likely that they mask something. Usually the print will contain a string, and this extra storage changes the memory layout, masking the bug.</p> <p>It sounds like you've already identified a location in the code where the pointer is corrupt.</p> <p>Typically this is hunted down by removing code (use #if 0 ... #endif) between the start of the program and the location where the bad pointer is discovered. A minimal progress marker is to switch LEDs on or off; less code needs to work than using SerialUSB, or print something on the serial port.</p> <p>Another tactic is to put extra variables (e.g. arrays) between structures. In the simple case, initialise the extra arrays to 0, and occasionally check to see if their value has been corrupted.</p> <p>If you are very stuck, and have the knowledge, you might try to substitute your own handler which could dump all of the registers to the serial port, giving you a lot more clues. Alternatively, you might get an ST-LINK/V2, and use texane/st-link software at github to run gdb.</p> <p>(full disclosure: I am not a member of LeafLabs staff.) </p> http://forums.leaflabs.com/topic.php?id=2642#post-13099 Mon, 03 Sep 2012 08:45:53 +0000 palsor 13099@http://forums.leaflabs.com/ <p>Hey guys,</p> <p>Has anyone has any strange problems with memory locations depending on code size or alignment? In our current project, my friend and I are using a Maple Mini. We are reading from several sensors, and most of the time everything works just fine, but sometimes when we build, the LED on the board to throb, which I assume is from a fault of some sort. If the build doesn't work, we can make it start working by simply inserting several SerialUSB.println() statements. This makes me thing the issue either has to do with adding additional delays into the code (the time required to do the serial writes), or the location/alignment of the code itself (adding the extra println's adds extra instructions and causes the code below it to move within in the image when compiled).</p> <p>I've tried simply adding a delay into the code with delay(5), and that didn't help, so I don't think it's a timing or delay issue.</p> <p>I've tried looking at the memory locations of various bits of code and data structures in passing and failing cases. We are storing most of our data in some global data structures. In passing cases, those data structures get stored at addresses in the 0x20001000-ish range, which makes sense to me. In the failing cases, when I look at the address of the data structure during setup(), it's in the 0x20001000-ish range, but when I look at the address of the data structure during loop(), it has moved to 0x2000D000 or 0x2000B000 or something similar, which doesn't make any sense to me. First, why would it move? Second, the Mini only has 20k of memory, and D000 or B000 is way outside of that range. </p> <p>My immediate thought was that maybe something went out of scope, or maybe a pointer has gotten overwritten or something, so I've been searching for that. However, what I can't figure out is why adding just a few SerialUSB.println() statements into my code somewhere seems to fix everything. I can't figure out why code alignment would have anything to do with this.</p> <p>I've also tried connecting an FTDI cable up to Serial2 to try and watch for debug data coming back when the Maple Mini crashes, but I haven't seen anything come back. I've got the FTDI cable connected, and I've got a terminal window open, connected, and set to 9600 baud. Is there anything else I need to do? My understanding is that if you run into a hard fault, there is no debug data that comes back, so I'm wondering if that's what is happening here.</p> <p>Anyway, has anyone seen anything like this? Any suggestions of anything to try?</p> <p>For reference, I'm on MapleIDE 0.0.12 on OSX 10.6.8 (Snow Leopard). We're using whichever version of libmaple came with MapleIDE.</p> <p>- Andy </p>