leaflabsandy
Member
Just curious - The Blue Status LED Throbbing.
Note: I am not using assert() and debug = 0.
During my testing, I am hammering the Maples's comports with everything they can take.
What condition(s) would cause the Maple blue status LED to throbb?
What is the state of the Maple (running/halted/?) in when this happens?
poslathian
LeafLabs
Oof. Throbbing = Hardfault
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!
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?
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.
leaflabsandy
Member
Quote: "Throbbing = Hardfault"
Reply: Translation - The ARM is halted in an infinite loop.
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?"
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?
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
info on this if you are interested."
Reply: A reset/POR will do it "IF" the condition is gone.
Maybe by using an enable flag, the hardfault would be printed to a serial port?
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.
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.
You must log in to post.
