Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    Kernel Panic when using SSL connections (MQTT or HTTPS)

    Scheduled Pinned Locked Moved LoPy
    sslmqtthttps
    6 Posts 2 Posters 2.1k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A Offline
      aktivalux
      last edited by aktivalux

      Hello,

      I am using the LoPy and PySense board. For testing I use WiFi connectivity. When connected via WiFi I want to send the data via MQTT or HTTP. In both cases I want to use SSL. However when I try to do so my LoPy crashes due to some kernel panic and I have no idea why. If using non-SSL it works for both, MQTT and HTTP connections.

      Am I missing something? Do I have to provide the trusted CAs somewhere? The error message is not really helpful

      My main.py
      https://pastebin.com/JjksiJeZ

      The error output:
      https://pastebin.com/CdF48CGD

      For HTTP requests I used this library: https://github.com/micropython/micropython-lib/blob/master/urequests/urequests.py
      For MQTT I used https://github.com/micropython/micropython-lib/blob/master/umqtt.simple/umqtt/simple.py

      1 Reply Last reply Reply Quote 0
      • T Offline
        this.wiederkehr
        last edited by

        Debug exception reason: Stack canary watchpoint triggered (MPThread)

        There are canary bits at the end of the stack which I think get checked on the context switch of the os. These canary bits got overwritten most likely by the MPThread task or just another out of bounds memory access. This is the reason for the panic.

        As you are doing tls in the thread I can well imagine that the default allocated 4096bytes stack per thread are not enough.

        You can try to increase the stack allocated for the MPThread task:
        By calling
        _thread.stack_size([size])
        prior to createing the thread.

        See the documentatio for additional information:
        https://docs.pycom.io/chapter/firmwareapi/micropython/_thread.html

        1 Reply Last reply Reply Quote 1
        • A Offline
          aktivalux
          last edited by

          Thanks for replying. Indeed it looks like playing around with the stack_size gives "other" results. So basically I can interpret the error message as some kind of out of memory error, correct?

          I tried troubleshooting / improving mem consumption of my script but actually couldn't find anything (with my very limited python skills) which could cause high memory usage. Also I was wondering how this little code can exhaust the 512KB of RAM. So I added some print(gc.free_mem()) statements. Even tho I commented out my whole code it only returned 59200B of free mem. Is this expected?!

          1 Reply Last reply Reply Quote 0
          • T Offline
            this.wiederkehr
            last edited by

            There are two kind of memory usages referred to as the stack and the heap. Each os task has his own stack whereas the heap is shared betwee all the tasks. Search for it on google to get more elaborate explanation. You can not in general decrease the stack usage by optimizing memory usage. Stack usage has more to do with function call depth (how deep your function calls are nested), that is why it is so hard to determine a reasonable size for it (and is usualy done empirically).

            gives "other" results

            Do you mean successfull results?

            I also have something above 50kB of free mem in mind (this refers to the free heap).

            1 Reply Last reply Reply Quote 0
            • A Offline
              aktivalux
              last edited by

              I also have something above 50kB of free mem in mind (this refers to the free heap)

              Ok then I had just expected to have some more memory/heap for my variables and objects. Because when using e.g. MQTT it drops down to around 20KB of free mem - which is not too much tbh.

              Do you mean successfull results?

              The result of the HTTPs request (print(response.text)) gave me numbers like -35123 when making a request to https://httpbin.org/get but (at least I no longer got a kernel panic :) ). I haven't had time yet to check why and if for example something was wrong with the ca_cert used. When making a HTTP request I get the expected JSON response.

              1 Reply Last reply Reply Quote 0
              • T Offline
                this.wiederkehr
                last edited by

                @aktivalux said in Kernel Panic when using SSL connections (MQTT or HTTPS):

                -35123

                You mean it raises OSError: -35123? Actually -35123 beeing -0x8933 is out of the error range defined by mbedtls. Is there a typo in this numer?

                https://tls.mbed.org/api/error_8h.html

                1 Reply Last reply Reply Quote 0

                Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                With your input, this post could be even better 💗

                Register Login
                • 1 / 1
                • First post
                  Last post

                Pycom on Twitter

                Pycom