http://forums.leaflabs.com/topic.php?id=141 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:19:34 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=141#post-891 Mon, 30 Aug 2010 11:20:15 +0000 leaflabsandy 891@http://forums.leaflabs.com/ <p>Quote: "I think the best would be a very low default verbosity that could be modified by the user with a #define in the header of their code"</p> <p>Reply: Yep, keep it real simple. </p> http://forums.leaflabs.com/topic.php?id=141#post-890 Mon, 30 Aug 2010 10:26:05 +0000 bnewbold 890@http://forums.leaflabs.com/ <p>The hard fault (file, line number) is currently printed to Serial2. The mechanism for this adds crude debugging symbols to the usercode programs for every single ASSERT(), which contributes a couple kb to the bloated program size. Currently there is a MAPLE_DEBUG variable in the source code which can disable this feature. We just disabled it by default in the repositories but will probably come up with a more subtle solution like verbosity levels which can be modified in a makefile. </p> <p>Do you think it would be worth having a verbosity control in the IDE or just having DEBUG/RELEASE targets? I think the best would be a very low default verbosity that could be modified by the user with a #define in the header of their code instead of via a menu option or build target, but I haven't looked in to this option yet. </p> http://forums.leaflabs.com/topic.php?id=141#post-869 Sat, 28 Aug 2010 08:39:15 +0000 leaflabsandy 869@http://forums.leaflabs.com/ <p>Quote: "Throbbing = Hardfault"</p> <p>Reply: Translation - The ARM is halted in an infinite loop.</p> <p>Quote: "what caused this? My best guess is a memory access hardfault. This happens you go outof bounds on a buffer or derefence null. It could be a bug youve found by thrashing the comm port libs. If so it would be a great find! Care to share some code?"</p> <p>Reply: I am using Azeotech's Daq Factory Express to hammer the Maple's comports. By adjusting the polling parameters and the Maple's millis sketch code, I was able to stop the throbbing. Probably overflowing the buffers or the ARM's capability to respond to multiple polls with large blocks of data sent out from the ARM? </p> <p>Quote: "FYI it is possible to recover from hardfaults via overriding the exception handlers and doing your own thing. Id have to dig a little to get you more<br /> info on this if you are interested."</p> <p>Reply: A reset/POR will do it "IF" the condition is gone.</p> <p>Maybe by using an enable flag, the hardfault would be printed to a serial port? </p> http://forums.leaflabs.com/topic.php?id=141#post-860 Fri, 27 Aug 2010 22:16:45 +0000 poslathian 860@http://forums.leaflabs.com/ <p>Oof. Throbbing = Hardfault</p> <p>which hardfault? err...currently you cant differentiate between the different kinds, they all throb. The state of the chip is that its sitting in a while(true){throb} loop inside of some hard fault exception handler. Weve been throwing out lots of ideas (internally) about a "better way" to deal with hardfaults, so were on it! </p> <p>what caused this? My best guess is a memory access hardfault. This happens you go out of bounds on a buffer or derefence null. It could be a bug youve found by thrashing the comm port libs. If so it would be a great find! Care to share some code? </p> <p>FYI it is possible to recover from hardfaults via overriding the exception handlers and doing your own thing. Id have to dig a little to get you more info on this if you are interested. </p> http://forums.leaflabs.com/topic.php?id=141#post-855 Fri, 27 Aug 2010 18:07:49 +0000 leaflabsandy 855@http://forums.leaflabs.com/ <p>Just curious - The Blue Status LED Throbbing.</p> <p>Note: I am not using assert() and debug = 0.<br /> During my testing, I am hammering the Maples's comports with everything they can take.</p> <p>What condition(s) would cause the Maple blue status LED to throbb?</p> <p>What is the state of the Maple (running/halted/?) in when this happens? </p>