Copyright © https://mongoose-os.com

Mongoose OS Forum

frame

Unable to flash firmware

Hello, I have an ESP8266 NodeMCU board. I install mos with the command curl -fsSL https://mongoose-os.com/downloads/mos/install.sh | /bin/sh, connected the board to USB (I can see it at /dev/ttyUSB0) and then tried to flash the firmware:
mos flash mos-esp8266 2> log_file
The content of log_file is the following:

Fetching https://mongoose-os.com/downloads/mos-esp8266.zip...
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x14 pc=0xc2d35691]

runtime stack:
runtime.throw(0x8704cee, 0x2a)
    /usr/local/go/src/runtime/panic.go:566 +0x7f
runtime.sigpanic()
    /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x59

goroutine 62 [syscall, locked to thread]:
runtime.cgocall(0x8553fc0, 0xd788ceb0, 0x0)
    /usr/local/go/src/runtime/cgocall.go:131 +0x125 fp=0xd788ce88 sp=0xd788ce6c
net._C2func_getaddrinfo(0xab5fd78, 0x0, 0xd79812a0, 0xd78a32a0, 0x0, 0x0, 0x0)
    ??:0 +0x4b fp=0xd788ceb0 sp=0xd788ce88
net.cgoLookupIPCNAME(0xd7980ec0, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/cgo_unix.go:146 +0x355 fp=0xd788cf70 sp=0xd788ceb0
net.cgoIPLookup(0xd79593c0, 0xd7980ec0, 0xf)
    /usr/local/go/src/net/cgo_unix.go:198 +0x2d fp=0xd788cfd0 sp=0xd788cf70
runtime.goexit()
    /usr/local/go/src/runtime/asm_386.s:1612 +0x1 fp=0xd788cfd4 sp=0xd788cfd0
created by net.cgoLookupIP
    /usr/local/go/src/net/cgo_unix.go:208 +0x11e

goroutine 1 [select]:
net/http.(*Transport).getConn(0xd78040a0, 0xd7988580, 0x0, 0xd7958f00, 0x5, 0xd7980ec0, 0x13, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/http/transport.go:890 +0x99d
net/http.(*Transport).RoundTrip(0xd78040a0, 0xd78a8580, 0xd78040a0, 0x0, 0x0)
    /usr/local/go/src/net/http/transport.go:367 +0xa97
net/http.send(0xd78a8580, 0x89a76b0, 0xd78040a0, 0x0, 0x0, 0x0, 0x0, 0xd7988540, 0x0, 0x0)
    /usr/local/go/src/net/http/client.go:256 +0x521
net/http.(*Client).send(0x8ba0f30, 0xd78a8580, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/http/client.go:146 +0x127
net/http.(*Client).doFollowingRedirects(0x8ba0f30, 0xd78a8580, 0x87550f8, 0x31, 0x0, 0x0)
    /usr/local/go/src/net/http/client.go:528 +0x95f
net/http.(*Client).Get(0x8ba0f30, 0xd7958f00, 0x31, 0xd78a31c8, 0x0, 0x0)
    /usr/local/go/src/net/http/client.go:418 +0x92
net/http.Get(0xd7958f00, 0x31, 0xd77c3ce0, 0x0, 0x0)
    /usr/local/go/src/net/http/client.go:393 +0x3f
cesanta.com/mos/flash/common.NewZipFirmwareBundle(0xd7958f00, 0x31, 0x0, 0x0, 0x0)
    /go/src/cesanta.com/mos/flash/common/fw_bundle_zip.go:34 +0xde4
main.flash(0x89ab9e0, 0xd77ec018, 0x0, 0x0, 0x0)
    /go/src/cesanta.com/mos/flash.go:84 +0xc4
main.run(0xd789f830, 0x89ab9e0, 0xd77ec018, 0x0, 0x0, 0x0)
    /go/src/cesanta.com/mos/main.go:113 +0xad
main.main()
    /go/src/cesanta.com/mos/main.go:198 +0x68e

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_386.s:1612 +0x1

goroutine 19 [select]:
cesanta.com/vendor/github.com/golang/glog.(*loggingT).flushDaemon(0x8ba1360)
    /go/src/cesanta.com/vendor/github.com/golang/glog/glog.go:927 +0x14b
created by cesanta.com/vendor/github.com/golang/glog.init.1
    /go/src/cesanta.com/vendor/github.com/golang/glog/glog.go:441 +0x262

goroutine 60 [select]:
net.lookupIPContext(0x89aba20, 0xd7959340, 0xd7980ec0, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/lookup.go:122 +0x72d
net.internetAddrList(0x89aba20, 0xd7959340, 0x86e5cac, 0x3, 0xd7980ec0, 0x13, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/local/go/src/net/ipsock.go:241 +0x4f1
net.resolveAddrList(0x89aba20, 0xd7959340, 0x86e6339, 0x4, 0x86e5cac, 0x3, 0xd7980ec0, 0x13, 0x0, 0x0, ...)
    /usr/local/go/src/net/dial.go:179 +0x6cc
net.(*Dialer).DialContext(0xd77e41c0, 0x89aba20, 0xd7959340, 0x86e5cac, 0x3, 0xd7980ec0, 0x13, 0x0, 0x0, 0x0, ...)
    /usr/local/go/src/net/dial.go:329 +0x4d9
net.(*Dialer).DialContext-fm(0x89ab9e0, 0xd77ec018, 0x86e5cac, 0x3, 0xd7980ec0, 0x13, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/http/transport.go:43 +0x68
net/http.(*Transport).dial(0xd78040a0, 0x89ab9e0, 0xd77ec018, 0x86e5cac, 0x3, 0xd7980ec0, 0x13, 0x0, 0x0, 0x0, ...)
    /usr/local/go/src/net/http/transport.go:826 +0x70
net/http.(*Transport).dialConn(0xd78040a0, 0x89ab9e0, 0xd77ec018, 0x0, 0xd7958f00, 0x5, 0xd7980ec0, 0x13, 0x847f901, 0x0, ...)
    /usr/local/go/src/net/http/transport.go:967 +0x199a
net/http.(*Transport).getConn.func4(0xd78040a0, 0x89ab9e0, 0xd77ec018, 0xd7980ee0, 0xd7959100)
    /usr/local/go/src/net/http/transport.go:885 +0x48
created by net/http.(*Transport).getConn
    /usr/local/go/src/net/http/transport.go:887 +0x3a0

goroutine 61 [select]:
net.cgoLookupIP(0x89aba20, 0xd7959340, 0xd7980ec0, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0, 0xd77a4a00)
    /usr/local/go/src/net/cgo_unix.go:209 +0x346
net.lookupIP(0x89aba20, 0xd7959340, 0xd7980ec0, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/lookup_unix.go:70 +0x82
net.glob..func11(0x89aba20, 0xd7959340, 0x8754fd0, 0xd7980ec0, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/hook.go:19 +0x54
net.lookupIPContext.func1(0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/net/lookup.go:119 +0x6d
internal/singleflight.(*Group).doCall(0x8ba0c78, 0xd789f920, 0xd7980ec0, 0xf, 0xd7980f80)
    /usr/local/go/src/internal/singleflight/singleflight.go:93 +0x21
created by internal/singleflight.(*Group).DoChan
    /usr/local/go/src/internal/singleflight/singleflight.go:86 +0x31f

I'm on Arch Linux

>uname -a
Linux 4.10.2-1-ARCH #1 SMP PREEMPT Mon Mar 13 17:13:41 CET 2017 x86_64 GNU/Linux

The command mos console works perfectly and the board works with other firmwares. Any idea? Thanks.

Comments

  • rojerrojer Dublin, Ireland

    hm, something going wrong during http fetch it seems.
    does it work if you fetch the url manually (with wget or curl -O)?

  • I'm able to download it manually:
    https://mongoose-os.com/downloads/mos-esp8266.zip and then flash it.
    But it seems I can't do it automatically. Thanks for the tip anyway.

  • atmegaatmega Schweiz

    I initially thought it's my error, but I have problems with the mos tool atm, too: I get Error: error response: 500: %!(EXTRA string=unknown swmodule type: 0) when trying to build using the cloud, even though local builds work. I only use the https://github.com/cesanta/mjs module...

  • SergeySergey Dublin, Ireland

    @atmega could you tell your OS and the sequence of steps for us to reproduce, please?

  • atmegaatmega Schweiz
    edited March 20

    I'm compiling on OSX 10.11.4
    Using the following main.c
    `#include <stdio.h>

    include "common/platform.h"

    include "common/cs_file.h"

    include "fw/src/mgos_app.h"

    include "fw/src/mgos_gpio.h"

    include "fw/src/mgos_sys_config.h"

    include "fw/src/mgos_timers.h"

    include "fw/src/mgos_hal.h"

    include "fw/src/mgos_dlsym.h"

    include "mjs.h"

    include "user_interface.h"

    include "espnow.h"

    enum mgos_app_init_result mgos_app_init(void) {
    esp_now_init();

    return MGOS_APP_INIT_SUCCESS;
    }`
    I get the error. When commenting out "esp_now_init();" it compiles without an error.
    EDIT: No Idea why the text is big o_O

  • I can't even mos init or mos build from command line. Right now it's unusable to me, is it me or is there a issue with servers?

  • @atmega ,

    I initially thought it's my error, but I have problems with the mos tool atm, too: I get Error: error response: 500: %!(EXTRA string=unknown swmodule type: 0) when trying to build using the cloud

    We've recently changed the way modules in mos.yml should be used. Now it's much more flexible, but yeah, that's a breaking change, sorry about that!

    So, first of all, please download the latest mos tool. Then, take a look at how modules are used in our mjs_base example: https://github.com/cesanta/mongoose-os/blob/master/fw/examples/mjs_base/mos.yml and make the appropriate changes to your projects. There are two things:

    • Instead of src, please use origin for the module URL
    • You need to explicitly reference your module in sources and/or filesystem, like this:
    sources:
      - src
      - ${mjs_path}
    filesystem:
      - fs
      - ${mongoose_os_path}/fw/mjs_api/api_*.js
    

    So, e.g. for the module foo, there is a variable ${foo_path} which you can use. Also, there is an implicit module mongoose-os, path to which can be referenced as ${mongoose_os_path}.

    Using the following main.c ..... I get the error. When commenting out "esp_now_init();" it compiles without an error.

    I assume it's a separate issue: where are espnow.h and the corresponding source file located? And please share your entire mos.yml.

  • edited March 20

    @dSYNCretism ,

    I can't even mos init or mos build from command line. Right now it's unusable to me, is it me or is there a issue with servers?

    Hm, it works fine for me. So I assume you can download the skeleton (which is used by mos init) manually?

    wget http://mongoose.cloud/downloads/skeleton.zip
    
  • @dimonomid said:
    dSYNCretism ,
    ```

    Thanks, I'll let you know as soon as I can try it.

  • atmegaatmega Schweiz

    @dimonomid Well, that explains it. Yes, I noticed, I was posting in the wrong thread. The other problem I explained in https://forum.cesanta.com/index.php?p=/discussion/296/esp-now#latest

  • @dSYNCretism said:

    Tried in a Kali Linux Virtual Machine and it worked, so I guess it's a Archlinux related issue. Any clue? I'd like to use it native.

  • Sorry if I bother you again. Is there a way to build a project without connecting to the internet (since I can't appearently)?

  • edited March 20

    Tried in a Kali Linux Virtual Machine and it worked, so I guess it's a Archlinux related issue. Any clue?

    Well, not at the moment. Probably I have to install Arch in the virtualbox and try mos there, although it's really weird.

    Is there a way to build a project without connecting to the internet

    You can use the flag --local, then mos will run the build locally; you'll need to install Docker for that to work.

  • edited March 20

    W.r.t. local build: mos will still download mongoose-os repository (and all modules which are listed in mos.yml). Then mos will invoke make, which will download docker image when runs for the first time. I have no idea if you'll experience problems with those downloads.

    Anyway, you can specify path to the locally cloned mongoose-os repo and all modules, typically the command I use is like this:

    mos build --local --arch esp8266 --repo=/path/to/mongoose-os --module=mjs:/path/to/mjs --verbose --clean
    

    Then, mos won't try to download these repos. If there are problems with docker image downloads, you can pull the image manually with docker pull (you'll see the name of the image which make tries to download)

  • I know, it's weird but I wasn't able to figure out why it has this behavior. It should be a issue with GO (which I don't even have installed, and installing didn't solve anything).

    Anyway: I have docker installed, I don't get what I have to do (make is never invoked). Thanks for the help anyway, I really appreciate it.
    Why isn't possible having a local toolchain?

  • edited March 20

    Anyway: I have docker installed, I don't get what I have to do (make is never invoked). Thanks for the help anyway, I really appreciate it.

    In a simplest case, in order to build the firmware locally, you need to do the following:

    • Navigate to your project which you want to build
    • Invoke mos build --local --arch esp8266 --verbose --clean

    I verified that it works for the example mjs_base (located at mongoose-os/fw/examples/mjs_base). If it doesn't work for you, please post the full log.

    Why isn't possible having a local toolchain?

    mos build --local does use a local toolchain: basically it invokes make with the right arguments. Technically one can invoke make with lots of arguments manually, but using mos is easier, and make isn't our public interface anyway.

    If by local toolchain you mean build things without even docker: technically it's possible as well, but there is a lot of stuff to install, patch, etc; I'm not ready to tell exact steps. It's really convenient to have everything packed into the docker image, and invoke toolchain from there.

  • Thanks a lot, you've been very helpful: I'm now able to compile it with no issues.
    Let me know if someone is able to find out what's happening on archlinux.
    Have a nice one.

  • Glad it helped.

    Yeah, I'll write here once we figure what's wrong on Arch.

Sign In or Register to comment.