Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    DrBomb
    @DrBomb
    I need to dig deeper on some issues but the breakpoints don't seem to be working
    hdmt-hock
    @hdmt-hock

    Hi everyone, I am having strange issue when define the following in mos.yml in current mos 2.18

      - ["wifi.ap.ip", "10.10.10.1"]
      - ["wifi.ap.gw", "10.10.10.1"]
      - ["wifi.ap.dhcp_start", "10.10.10.2"]
      - ["wifi.ap.dhcp_end", "10.10.10.11"]

    When only 1x esp8266 is running, the definition works ok with 2 wifi AP connection. Meaning I could connect to the esp8266 via AP mode using iphone and mac mini at the same time on my test table. Test on another seperate esp8266 in a different office, we could connect win pc and sumsung handy.
    What is not working! when more esp8266 is running with the same definition above in the same room, no AP access possible.
    if the above definition is removed from mos.yml and using default value, all esp8266 works with AP mode correctly. Appreciate if someone could give some light on this 4 wifi.ap.* definition, just a reminder, these definition has been in use and working in mos 2.17 and before.

    gadget-man
    @gadget-man
    Isn’t it simply a matter of an IP conflict - if you have 2 esp8266 devices, both of which are in AP mode broadcasting 10.10.10.1 as their IP address and they are in the same room, how will your iphone know which one to connect to?
    d4rkmen
    @d4rkmen
    by ssid. its different. and even if its the same, these are different networks anyway
    Deomid Ryabkov
    @rojer

    I need to dig deeper on some issues but the breakpoints don't seem to be working

    hm, strange. no, i have not tried breakpoints

    got ESP-IDF upgraded to 4.2-rc, seems to be ok. will do some more testing
    gadget-man
    @gadget-man
    OOOh, that’s exciting!
    Deomid Ryabkov
    @rojer
    this is the first step to ESP32S2 support
    gadget-man
    @gadget-man
    (I’m easily pleased)
    Deomid Ryabkov
    @rojer
    he-he :)
    gadget-man
    @gadget-man
    I’m finding I sometimes get a corrupt heap error / crash when trying to update AWS shadow twice in quick succession. Is there a way (in mjs - sorry) to check if a shadow update is already in progress, and if so wait a few ms?
    Deomid Ryabkov
    @rojer
    hm... no, i don't think there is
    gadget-man
    @gadget-man
    Here’s my core dump. Am I missing anything obvious?
    [Nov 24 21:00:56.547] CORRUPT HEAP: multi_heap.c:432 detected at 0x687ce4e6
    [Nov 24 21:00:56.547] abort() was called at PC 0x4008fa4f on core 0
    [Nov 24 21:00:56.553] 
    [Nov 24 21:00:56.553] ELF file SHA256: 478f959a89838e49
    [Nov 24 21:00:56.559] 
    [Nov 24 21:00:56.559] Backtrace: 0x4008bbb7 0x4008bd35 0x4008fa4f 0x4008fdff 0x400838e3 0x400839a2 0x4014369d 0x40143763 0x401437e8 0x40145035 0x4014518a 0x40145215 0x40141230
    [Nov 24 21:00:56.570] 
    [Nov 24 21:00:56.570] 
    [Nov 24 21:00:56.570] --- BEGIN CORE DUMP ---
    [Nov 24 21:00:56.575] mos: catching core dump
    [Nov 24 21:00:59.432] .............
    [Nov 24 21:01:36.457] ---- END CORE DUMP ----
    [Nov 24 21:01:36.464] mos: wrote to /Users/PaulNeedler/Documents/iParcelBox/3-FIRMWARE/iParcelBox_firmware.nosync/core-iParcelBox_firmware-esp32-20201124-210136.414167693 (459474 bytes)
    [Nov 24 21:01:36.464] mos: analyzing core dump
    Core dump by iParcelBox_firmware/esp32 1.3.1 20201124-201722/g1700f3f-1.3
    Using ELF file at: /Users/PaulNeedler/Documents/iParcelBox/3-FIRMWARE/iParcelBox_firmware.nosync/build/objs/iParcelBox_firmware.elf
    Using Docker image: docker.io/mgos/esp32-build:3.3-r5
    Running docker run --rm -v /Users/PaulNeedler/Documents/iParcelBox/3-FIRMWARE/iParcelBox_firmware.nosync/build/objs/iParcelBox_firmware.elf:/fw.elf -v /Users/PaulNeedler/Documents/iParcelBox/3-FIRMWARE/iParcelBox_firmware.nosync/core-iParcelBox_firmware-esp32-20201124-210136.414167693:/core -v /Users/PaulNeedler/Documents/iParcelBox/3-FIRMWARE/iParcelBox_firmware.nosync:/Users/PaulNeedler/Documents/iParcelBox/3-FIRMWARE/iParcelBox_firmware.nosync docker.io/mgos/esp32-build:3.3-r5 bash -c /usr/local/bin/serve_core.py --rom=/opt/Espressif/rom/rom.bin --rom_addr=0x40000000 --xtensa_addr_fixup=true /fw.elf /core & $MGOS_TARGET_GDB /fw.elf -ex 'target remote 127.0.0.1:1234' -ex 'set confirm off' -ex bt -ex quit
    GNU gdb (crosstool-NG crosstool-ng-1.22.0-96-g2852398) 7.10
    Copyright (C) 2015 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from /fw.elf...done.
    Remote debugging using 127.0.0.1:1234
    0x4008bbb7 in invoke_abort ()
        at /opt/Espressif/esp-idf/components/esp32/panic.c:156
    156            *((int *) 0) = 0;
    #0  0x4008bbb7 in invoke_abort ()
        at /opt/Espressif/esp-idf/components/esp32/panic.c:156
    #1  0x4008bd38 in abort ()
        at /opt/Espressif/esp-idf/components/esp32/panic.c:171
    #2  0x4008fa52 in multi_heap_assert (condition=false, line=432, 
        address=1753015526, 
        format=0x3ffb2dbf "CORRUPT HEAP: multi_heap.c:%d detected at 0x%08x\n")
        at /opt/Espressif/esp-idf/components/heap/multi_heap_platform.h:54
    #3  0x4008fe02 in multi_heap_malloc_impl (heap=0x3f800000, size=16)
        at /opt/Espressif/esp-idf/components/heap/multi_heap.c:432
    #4  0x400838e6 in heap_caps_malloc (size=16, caps=5120)
        at /opt/Espressif/esp-idf/components/heap/heap_caps.c:111
    #5  0x400839a5 in heap_caps_malloc_prefer (size=16, num=1)
        at /opt/Espressif/esp-idf/components/heap/heap_caps.c:193
    #6  0x401436a0 in mem_malloc (size=16)
        at /opt/Espressif/esp-idf/components/lwip/lwip/src/core/mem.c:149
    #7  0x40143766 in do_memp_malloc_pool (desc=<optimized out>)
        at /opt/Espressif/esp-idf/components/lwip/lwip/src/core/memp.c:301
    #8  0x401437eb in memp_malloc (type=<optimized out>)
        at /opt/Espressif/esp-idf/components/lwip/lwip/src/core/memp.c:398
    #9  0x40145038 in sys_timeout (msecs=500, handler=0x40145178 <cyclic_timer>, 
        arg=0x3f41b4d0 <
    Deomid Ryabkov
    @rojer
    something definitely stomped on some memory
    hard to say more, unfortunately... if you can distill it down to a small app that reproduces it, i will take a look
    gadget-man
    @gadget-man
    I added a hw_timer to check for GPIO changes on boot - wondering if I’ve messed it up so will try removing that first...
    gadget-man
    @gadget-man
    It was my own stupidity - insufficient power via USB when powering lock at the same time as Tx.
    hdmt-hock
    @hdmt-hock
    if 10.10.10.1 is conflict with another esp8266, then 192.168.4.1 (default ip) should also cause conflict, but 192.168.4.1. works ok and not 10.10.10.1
    Deomid Ryabkov
    @rojer
    @hdmt-hock just tested your settings and had no problem conecting 3 devices
    all of them were able to access web server at 10.10.10.1
    suyashmathema
    @suyashmathema
    @rojer I am not able to set the build ID. I tried doing mos build --platform esp32 --local --verbose --build-var=GEN_BUILD_INFO_EXTRA=--id=foo, mos build --platform esp32 --local --verbose --build-var "GEN_BUILD_INFO_EXTRA=--id=foo", mos build --platform esp32 --local --verbose --build-var=GEN_BUILD_INFO_EXTRA="--id foo" and still it is setting the build id with branch-name + dirty. I even tried by creating a new repository but the dirty suffix is still present. Checked the mos cli source --dirty flag is set to auto and but still I get the 'dirty' suffix in the build id.
    Liviu
    @nliviu

    @suyashmathema Here are my findings regarding build_id:

    git clone https://github.com/mongoose-os-apps/empty
    cd empty
    mos build --local  --platform esp32 --build-var=GEN_BUILD_INFO_EXTRA=--id=foo
    cat build/gen/build_info.c
    /* Auto-generated, do not edit. */
    const char *build_id = "20201125-073144/2.13.0-ge44f822-master";
    const char *build_timestamp = "2020-11-25T07:31:44Z";
    const char *build_version = "1.0";
    
    mos build --local  --platform esp8266 --build-var=GEN_BUILD_INFO_EXTRA=--id=foo
    cat build/gen/build_info.c
    /* Auto-generated, do not edit. */
    const char *build_id = "foo";
    const char *build_timestamp = "2020-11-25T07:33:56Z";
    const char *build_version = "1.0";

    Looks like when building for ESP32, GEN_BUILD_INFO_EXTRA is ignored.

    Mark
    @markterrill
    Hi folk. I've gone through the efuse docu and some of the go code, but it's obviously a fairly deep field. What I'm trying to do is just use one key for all devices (yes, I know it's not as good as separate, but each device doesn't have anything sensitive of the client's stored on it). Does anyone happen to know the command(s) to use ?
    Mark
    @markterrill
    This is from esp32_key_gen.go:
    {
                {"flash_crypt_cnt", 1, true}, // write-protect the counter so encryption cannot be disabled.
                {"JTAG_disable", 1, false},
                {"download_dis_encrypt", 1, false},
                {"download_dis_decrypt", 1, false},
                {"download_dis_cache", 1, false},
                {"flash_crypt_config", 0xf, false},
            }
    and a dry run using the more generic esp32-key-gen command showed that it would execute:
    flash_encryption_key : 08866f9d1de7d291afbda7a8ff14345056e5da9bcdd74de6ee9839xxxxxx
    efuse_rd_disable     : 0x0 -> 0x1
    efuse_wr_disable     : 0x0000 -> 0x0084
    flash_crypt_cnt      : 0x00 -> 0x01
    JTAG_disable         : 0x0 -> 0x1
    download_dis_encrypt : 0x0 -> 0x1
    download_dis_decrypt : 0x0 -> 0x1
    download_dis_cache   : 0x0 -> 0x1
    flash_crypt_config   : 0x0 -> 0xf
    Mark
    @markterrill
    ... currently figuring out how to modify the key-gen command to (not entirely sensibly) observe the esp32-encryption-key-file argument
    gadget-man
    @gadget-man

    @daadu_gitlab , smth like

    mos esp32-efuse-set flash_encryption_key=0x0000000000000000000000000000000000000000000000000000000000000000 flash_encryption_key.RD=1 flash_encryption_key.RD=1 flash_crypt_cnt=1 flash_crypt_cnt.WD=1 JTAG_disable=1 download_dis_encrypt=1 download_dis_decrypt=1 download_dis_cache=1 flash_crypt_config=0xf

    @markterrill see above previous post by @rojer from Dec 19.

    Mark
    @markterrill
    oh thanks!
    I should have searched more! That'd have been a shitload easier than reworking the mos tool (first time coding in Go!)
    ps, it's actually working with my modification. Added an extra flag so it will read the file rather than write to it.
    kinda cool, though the esp32-gen-key command could potentially be renamed as esp32-fuse-key to be ambidextrous ;)
    Mark
    @markterrill
    If this is remotely interesting to cesanta folk, this is the gist: https://gist.github.com/markterrill/5ebdc124eed05fcaf4cf767debadbb3a
    Mark
    @markterrill
    For posterity have also done a docu PR with that line!
    cesanta/mongoose-os-docs#44
    Mark
    @markterrill
    ah. the gist url updated: https://gist.github.com/markterrill/53bf7e05aef05a39f8e2d16ee23660d4
    I'd foolishly thought I'd stuffed something up. Just needed to flash the image again with the key.
    hdmt-hock
    @hdmt-hock
    Hello, any info on what 684 means in esp_main.c:158 SDK: mac 684 ?
    [Nov 25 11:24:54.144] mgos_http_server.c:180  0x3fff2134 HTTP connection from 192.168.0.4:52088
    [Nov 25 11:24:55.150] mgos_ota_core.c:252     Starting, timeout 600, commit timeout 0, mem 35116
    [Nov 25 11:24:55.168] mgos_ota_core.c:486     FW: chi_smart esp8266 7.00 20201125-142430/g823dd97-master-dirty
    [Nov 25 11:24:55.180] esp_ota_backend.c:185   Slot 0, FW: chi_smart.bin -> 0x100000, FS fs.bin -> 0x8000
    [Nov 25 11:24:55.449] esp_ota_backend.c:338   Start writing chi_smart.bin (669168) @ 0x100000
    [Nov 25 11:24:55.587] mgos_ota_core.c:504     0.22% total, chi_smart.bin 512 of 669168
    [Nov 25 11:24:58.765] mgos_ota_core.c:504     28.23% total, chi_smart.bin 262656 of 669168
    [Nov 25 11:25:00.545] esp_main.c:158          SDK: mac 684
    [Nov 25 11:25:27.472] 
    [Nov 25 11:25:27.472] HW WDT @ 0x40102dca
    [Nov 25 11:25:27.472]  A0: 0x40102dca  A1: 0x3ffffcf0  A2: 0x00000008  A3: 0x00000000
    [Nov 25 11:25:27.472]  A4: 0x00000000  A5: 0x000000ff  A6: 0x40294b80  A7: 0x3fffd9f0
    [Nov 25 11:25:27.472]  A8: 0x00000025  A9: 0x00000170 A10: 0x000000dd A11: 0x00000004
    [Nov 25 11:25:27.472] A12: 0x00000013 A13: 0x00000002 A14: 0x00040000 A15: 0x00002000
    [Nov 25 11:25:27.472] 
    [Nov 25 11:25:27.472] (exc SP: 0x3ffffb30)
    [Nov 25 11:25:27.472] 
    [Nov 25 11:25:27.472] --- BEGIN CORE DUMP ---
    [Nov 25 11:25:27.473] mos: catching core dump
    [Nov 25 11:25:30.315] ....
    [Nov 25 11:25:38.968] ---- END CORE DUMP ----
    This happen randomly during OTA update but not consistent, most time re-doing OTA will be ok.
    hdmt-hock
    @hdmt-hock
    Also 684 appear randomly on other occasion, sometime system recover without crash and reset, most time core dump.
    Marcus Hoffmann
    @hoffmann-m
    Is it possible to add new key/values to manifest.json within the build process?
    Greg Oleksiak
    @goleksiak
    Anyone running a new M1 Mac seen better build performance?
    Deomid Ryabkov
    @rojer
    i seriously doubt it, as it will need to emulate amd64 to run our toolchain
    if it's possible at all, it's bound to be slower
    suyashmathema
    @suyashmathema
    @nliviu I am not able to get id without dirty suffix. Which version are you using?
    git clone https://github.com/mongoose-os-apps/empty
    Cloning into 'empty'...
    remote: Enumerating objects: 121, done.
    Receiving objects:  63% (77/121)sed 0 (delta 0), pack-reused 121Receiving objects:  62% (76/121)
    Receiving objects: 100% (121/121), 19.03 KiB | 79.00 KiB/s, done.
    Resolving deltas: 100% (63/63), done.
    cd .\empty\
    mos build --local  --platform esp32 --build-var=GEN_BUILD_INFO_EXTRA=--id=foo
    Fetching libmbedtls-esp32.a (2.17.0) from https://github.com/mongoose-os-libs/mbedtls/releases/download/2.17.0/libmbedtls-esp32.a...
    Fetching libmongoose-esp32.a (2.17.0) from https://github.com/mongoose-os-libs/mongoose/releases/download/2.17.0/libmongoose-esp32.a...
    Firmware saved to C:\Users\suyash\Desktop\empty\build\fw.zip
    By the way, there is a newer version available: "2.18.0" (you use "2.17.0"). Run "mos update" to upgrade.
    
    cat .\build\gen\build_info.json
    {
      "build_id": "20201125-173736/2.13.0-ge44f822-master-dirty",
      "build_timestamp": "2020-11-25T17:37:36Z",
      "build_version": "1.0"
    }
    Liviu
    @nliviu
    @suyashmathema Tested with release (2.18.0) and latest on a debian buster machine.
    Liviu
    @nliviu
    mos update 2.17.0
    mos build --local  --platform esp32 --build-var=GEN_BUILD_INFO_EXTRA=--id=foo
    cat build/gen/build_info.json 
    {
      "build_id": "20201125-175951/2.13.0-ge44f822-master",
      "build_timestamp": "2020-11-25T17:59:51Z",
      "build_version": "1.0"
    }
    Might be something related to git for Windows?
    Anyways, GEN_BUILD_INFO_EXTRA seems to be ignored in ESP32 builds.
    @rojer Any ideea?
    Liviu
    @nliviu
    @suyashmathema BTW, nice modbus library!
    suyashmathema
    @suyashmathema
    @nliviu thanks, still needs some works. Built in ubuntu, at least the dirty suffix is gone
    Deomid Ryabkov
    @rojer
    @nliviu interesting, will take a look