stm32F429: httprequest randomly freezing Hi.

I started this as a question but i think i got a better grasp at what is a question and a discussion, so while it is being reviewed (and most certainly refused as it should instead be a topic) I'll just drop it here too. Please forgive me for double post if that occurs and i am not able to delete the question. Also, i have some more information to add..

Here comes my problem...

I have a little simple program that is more or less randomly crashing (panic leds) or freeze when calling MBED-HTTP's HttpRequest constructor, and i can't figure out why. More or less randomly means that it used to run ok, then started to stop after some time, then more and more sooner, then now almost all the time at the same call.(third or fourth)

Program has no thread, i just run all in main. I have no interrupts, no timers, no nothing fancy. I tried compiling online with official compiler, offline with eclipse, same result. I tried reusing socket and letting HttpRequest opening it each request, same result. i tried getting an idea about memory usage and used this routine before calling constructor to get largest memory block and i have around free 80KB each time. (source https://os.mbed.com/questions/6800/How-to-find-the-amount-of-free-space-on-/ )

I also tried putting all my logic in a thread, started from main and adding a while(1) at the end of main() that 1hz blinked a LED to check if it was totally killed when frozen or not. It looks like in fact sometimes it crashes and panics, sometimes not in a short time enough so that i can see it happening. (minutes time span) 1Hz Led keeps on blinking while httpRequest does not return.

I believe i must be doing something illegal with the HttpRequest, but can't figure ou what. Thanks for any hint, i'm going mad and out of options.

More information: When it crashes, here is what i get on serial:

++ MbedOS Error Info ++
Error Status: 0x80010133 Code: 307 Module: 1
Error Message: Mutex: 0x2000A624, Not allowed in ISR context
Location: 0x80142F1
Error Value: 0x2000A624
Current Thread: application_unnamed_thread  Id: 0x20000F5C Entry: 0x8016651 StackSize: 0x1000 StackMem: 0x2000B2D8 SP: 0x2002FE58 
For more info, visit: https://mbed.com/s/error?error=0x80010133&osver=51301&core=0x410FC241&comp=2&ver=50400&tgt=NUCLEO_F429ZI
-- MbedOS Error Info --

= System will be rebooted due to a fatal error =
= Reboot count(=1) reached maximum, system will halt after rebooting ·

From what i read in the given URL, it seems to be an internal error, but i can not narrow it down.

Hi Frederic,

Regarding Mutex: 0x2000A624, would you find it in BUILD/*.map, to see what the mutex is?

And here is an issue of mutex in ISR, please check if it helps.

Regards, Desmond

Hi Desmond.

Thanks for taking time to look into this.

Here is what the map file says:

 COMMON         0x00000000200095e8     0x1058 mbed-os/rtos/TARGET_CORTEX/mbed_rtos_rtx.o
                0x00000000200095e8                singleton_mutex_id
                0x00000000200095f0                _main_stack
                0x000000002000a5f0                _main_thread_attr
                0x000000002000a614                singleton_mutex_attr
                0x000000002000a624                singleton_mutex_obj

Does not look great to me...

I checked this, but i use no console, no printf.. i have an lcd1602 display. Also, each time it crashes, i get a dump.

It is just that it does not come out of the constructor of httpRequest, or crashes while in it.

Desmond,

I am actually stuck with this problem. I tried looking into platform code for things that could use that mutex but I have to admit I got lost somewhere and could not progress.

Do you have any idea of what it could be or where I should focus? Any starting point would help me a lot, as I do not know anything about the inners of the platform.

Thanks.

Hi.

Is there still someone from ARM really active around here? Posts take days to be accepted, responses are scarce and follow-ups are somewhat inexistent. I find this intriguing.

I had a similar problem in my code ..

• You cannot have any serial communication inside an interrupt.. That is not allowed. No printf should be used inside an interrupt.
• Export your code and try to analyze the code using for example ( http://cppcheck.sourceforge.net).
• You might have some MEM leakage that causes the mbed to crash.. I could find mine using the mentioned tool.
• You can debug the code and disallowing reboot (edit the configuration file .. you will find a section for that). so you know what peaces of code is causing the problem and where in your code .. but do the previous mentioned steps before debugging.

Your LED in the thread will not function since mbed as whole is crashing ... Exactly the same problem I had and I tried many things .. Until I used the cpp check I couldn't figure out what was wrong. I hope this help

Hi. Thanks for taking time to come in.

I will take your points sequentially and give more information.

Fine and understood. My code uses no serial output so i take it out of the equation. In case you thought about communication to the display; it is not using serial, just bitbanging and never within an interrupt anyway.

Fair enough. Installed cppcheck 1.89 and had to -force check due to too many combinations . Checked the whole project. Mbedos had its "fair share" of uninitialized variables, pointer dereference usage and oob accesses, (scary number of them, by the way...) but nothing for my code. cppCheck has already been going over my code, but it is still running on mbed. If it ends up showing things back on my code, i'll post an update.

In a way, i already know what part is crashing: the constructor to HTTPRequest. What my investigations show is that there is a mutex being called during an interrupt, while in the constructor. HTTPRequest is not within my bounds, neither is any interrupt as i have none in my code. I tried getting into mbed platform code but boy, that is a huge task to start with.

With experience i've learned to get relax with any too strong feeling of "doing the right thing". I do accept that i might have borked mem with illegal accesses/wrong memory management, and i will check that with any other suggested tool anyone throws in. I have already done all my own checks and corrected whatever eclipse told me. No error or warning, while still in -wall. That is still a good start imho. May i trigger bad behavior in such parts just by twiddling memory? Theoretically, yes, everything can happen when you shoot around you. May i be the cause? I still doubt, seeing what the behaviour is and various code analysis tool tend to confort me in that direction.

LED was there to factually check for total crash, so we agree. When led stopped blinking i knew it was total dead and that there was a dump on the serial from the OS. When this problem is resolved, blink thread will be removed. However, it would sometime not crash but still not return from the constructor. Would that be a silent thread crash, i don't know. Is there a reliable mean to check this?

Again, thanks for chiming in.

CPPCheck analysis ended. I post it to pastebin for reference (and thrill)

https://pastebin.com/754dhSJG

Hi Frederic,

I am running this example on my K64F, to use a while(1) loop make it keep running GET/POST.

https://os.mbed.com/teams/sandbox/code/http-example/

It is running over 1 hour, still working well, would you try to run this example?

Thanks, Desmond

Hi Desmond. I'll be delayed due to offices being under water now, but i will test it by monday or tuesday. Thanks a lot for your help.

Hi Frederic,

Hope you are well, please take care yourself. Feel free to update this thread when you are available.

Hi Desmond.

Thanks for the kind words. Will take care, for sure.

i will find my way to test the app and i have something to report; i tried to export it for the f429ZI/eclipseGCC toolchain and got this error.

"Export failed to eclipse_gcc_arm for NUCLEO_F429ZI: Attempt to override undefined parameter 'mbed-http.http-buffer-size' in 'application[*]'"

i will try through online ide or any other means necessary this afternoon, could not spend more time at the moment, still work to do to recover office stuff.

Have a great day.