cesanta/mongoose-os

Mongoose OS community chat

DrBomb

@DrBomb

You will either have to define the variable as a global one and access it from the timer, or allocate the int to the heap and pass the allocated pointer to the userdata to be cast back on the callback

Brian Brietzke

@bbrietzke

Thank you @DrBomb, you are right. Here is what the correct ( or at least works for me ) code looks like:

  int *ledPin = (int *) calloc(1, sizeof(*ledPin));
  *ledPin = mgos_sys_config_get_board_led1_pin();

DrBomb

@DrBomb

Sergey Lyubka

@cpq

That is a weird construct. I think it should be something like this:

int *pin1 = &mgos_sys_config_get_board()->led1_pin;
mgos_set_timer(1000, MGOS_TIMER_REPEAT, timer_cb, pin1);

System configuration is a singleton, therefore getting addresses from nested structures should work just fine.

@bbrietzke allocating pointers, like you did, then assigning , would not make it reference a correct address, so your code seems wrong

Jan

@janko.valiska:matrix.org

[m]

Hi guys, is there option in mos tool to create RELEASE version of FW binary? So all strings like /home/MY_USER_NAME/... are stripped from final FW binary? Thank you.

abveenwall

@abveenwall

So, stupid question.. Is the 'mos clone' command broken or am I totally missing something ?

Liviu

@nliviu

It looks like it's broken

mos clone https://github.com/mongoose-os-apps/empty
Error: empty: Local copy in "empty" does not exist and fetching is not allowed
/src/cli/build/swmodule.go:262:
/src/cli/main.go:198: clone failed

abveenwall

@abveenwall

That's what I get across platforms as well. Okay, we'll do it the manual way - thanks @nliviu

Liviu

@nliviu

Never used mos clone. Always using git clone.

abveenwall

@abveenwall

Could be that the quickstart guide is old. I didn't have git on my Windows (work) machine, but that's what I'll end up doing for my linux devhost.

Sergio R. Caprile

@scaprile

I've seen this on the new release, there are two user reports here. I've had no problem in 2.18.0 (I've not upgraded yet)

hdmt-hock

@hdmt-hock

Hello, the mos build --clean --local --platform=ESP8266 is stuck at Docker arguments: run --name mos_build_ ... again. This is my 2nd build today, I had terminate a previous build and restart the build. The last time the mos build stuck at docker was about a week ago when using mos latest '74. Now with mos release 2.19.1 , same issue. Is this related to docker limitation of 200 container pull per 6 hr?

I did had a successful build yesterday but with 2.19.0 specified in mos.yml, today I remove and use ${mos_version}

hdmt-hock

@hdmt-hock

Interestingly, ${mos_version} works in AWS EC2 linux but not on mac os mojave. I replace the ${mos_version} with 2.19.1 in mac os mojave and the build runs.

hdmt-hock

@hdmt-hock

currently the mos build local on mac os mojave stuck at

CC    /Volumes/Hidromotic/github/hidromotic/acueducto_sarah/pozo/esp/build/gen/mg_build_info.c

for the last hour. CTRL-C and rebuild, restart docker and rebuild, clean and rebuild.. stuck at the above line. Is mos under some maintanence schedule?

Sergey Lyubka

@cpq

Local builds are local, there could not be any maintenance

hdmt-hock

@hdmt-hock

I left the build running since yesterday and still stuck in ´mg_build_info.c´

Marcus Hoffmann

@hoffmann-m

Hi, I try to upgrade my project to Mongoose-OS v2.19.1 and get this error wiht local build:

Generating esp32.project.ld
LD /home/mark_wahlberg/git/my-app/build/objs/my-app.elf
/opt/Espressif/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/mark_wahlberg/git/my-app/build/objs/mosapp/libmosapp.a(mgos_freertos_core_dump.c.o):(.text.mgos_freertos_core_dump+0x20): undefined reference to `mgos_freertos_extract_regs'
/opt/Espressif/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/mark_wahlberg/git/my-app/build/objs/mosapp/libmosapp.a(mgos_freertos_core_dump.c.o): in function `mgos_freertos_core_dump':
/home/mark_wahlberg/git/my-app/deps/freertos/src/mgos_freertos_core_dump.c:40: undefined reference to `mgos_freertos_extract_regs'
collect2: error: ld returned 1 exit status
make: *** [/home/mark_wahlberg/git/my-app/build/objs/my-app.elf] Error 1
/opt/Espressif/esp-idf/make/project.mk:563: recipe for target '/home/mark_wahlberg/git/my-app/build/objs/my-app.elf' failed
make: Leaving directory '/app'

Does anyone have a clue for me?

Sergio R. Caprile

@scaprile

opened issue 41 regarding mos clone failing

Liviu

@nliviu

@hoffmann-m In the current version of esp-idf (4.2-r1), mgos_freertos_extract_regs definition is protected by CONFIG_ESP32_ENABLE_COREDUMP_TO_UART.

In previous versions there was simply a #if 1.

Liviu

@nliviu

@scaprile You reported in the wrong repo. It has been fixed in mongoose-os/mos#55.

Sergio R. Caprile

@scaprile

OK, Liviu, thanks, so it will come up fixed for 2.19.2+... thx again

Mark

@markterrill

Hi.. any ideas on this build error with mos deps? deps/vfs-fs-spiffs/src/mgos_vfs_fs_spiffs.c:837:3: error: too many arguments to function 'cs_base64_encode'

i checked the dep repo that it's pulled the latest

Mark

@markterrill

ignore me, found a build script was using the wrong mongoose-os repo to build against.

Marcus Hoffmann

@hoffmann-m

@nliviu Thanks! With esp-idf 4.2, CONFIG_ESP32_COREDUMP_ENABLE_TO_NONE has changed to CONFIG_ESP_COREDUMP_ENABLE_TO_NONE.

cnhyades

@cnhyades

Hi guys, I'm facing OTA reliability issues with some devices in the field. Always one or more devices failed to update. I'm using mDAsh to push the new firmware. After 100% progress the device reboots with the old version. Tried multiple times but no luck. Any idea why? I'm using OS version 2.19.1

Mark

@markterrill

Are you sure the commit timeout isn't timing out ?

cnhyades

@cnhyades

@markterrill I didn't modify the default value. Do you think that's short or could be problem? Any suggestion there?

Márk Antal Csizmadia

@mark-antal-csizmadia

Hi all, any idea what could I check if my OTA via HTTP GET is not working (and it was working 3 weeks ago).

I use a Google Cloud Storage bucket to store the fw.zip file, and generate a V4 signed key URL to download it, which is passed onto the mgos_ota_http_start function. The mgos_ota_http_start function receives the URL but does not start the OTA process - just seems stuck.

[Mar 11 10:06:49.741] mgos_ota_http_clien:270 Update URL: https://randomstorage.storage.googleapis.com/fw.zip?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=...
[Mar 11 10:06:49.869] mg_ssl_if_mbedtls.c:35  0x3fff6354 ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
[Mar 11 10:06:50.442] SW ECDSA verify curve 3 hash_len 32 sig_len 71
[Mar 11 10:06:55.666] SW ECDH curve 3
[Mar 11 10:07:00.587] mgos_mongoose.c:66      New heap free LWM: 6864

I am happy to share more of the code, but since it once was reliably working, I firmly believe that the issue is with credentials or something. I would appreciate your help, as I am really confused and disappointed that something that worked is not working after 2 weeks.

Andy Blackburn

@andyblac

I’m not an expert but, I’m pretty sure OTA does not support HTTPS, only HTTP protocol, you could try that ?

DrBomb

@DrBomb

OTA supports https, I've used it no problem as long as you have the correct trust chain and all that

Deomid Ryabkov

@rojer

@mark-antal-csizmadia please increase debug.level and debug.mbedtls_level

it should work

johndevereux

@johndevereux

Hi All - is it possible to repartion esp32 once flash encryption is enabled? Or will I lose access to it? Thanks, John.

(repartition)

Deomid Ryabkov

@rojer

no way to do it in the field, i'm afraid

at least no existing way. possible in theory, if you have enough space to move things arounf

johndevereux

@johndevereux

OK thanks - what about when its in front of me (sorry if it is stupid question)

Deomid Ryabkov

@rojer

then you can reflash it over serial

assuming you saved the encryption key when setting up encryption, you will always be able to reflash the device

johndevereux

@johndevereux

OK great, thank you very much!

Jan

@janko.valiska:matrix.org

[m]

Hi! Please is there a way how to use "vanilla" mbedtls with mongoose os? I need to use ssl client certificate authentication and also to configure MBEDTLS_SSL_RENEGOTIATION, but when i define it in cdefs section, the firmware will crash on every call to mg_use_cert() function. Every call fail with: heap integrity broken: free links don't match: 788 -> 868, but 868 -> 0.

Jan

@janko.valiska:matrix.org

[m]

I tought that this memory issue can be somehow related to "mongoose" changes that are made to vanilla mbedtls library... but i'm no 100% sure.

Deomid Ryabkov

@rojer

renegotiation is not supported in order to save ram

Jan

@janko.valiska:matrix.org

[m]

Hi, thank you for answer. It makes sense to turn off memory hungry features. But then, how can we connect to application service that is hosted for example on azure cloud, where there is application gateway in the front of the service? The first hanshake is made with application gateway, and then final service is making renegotiation request, since it requires client certification. But second handshake is definitelly rejected by device with alert message.

Deomid Ryabkov

@rojer

i think we can make it possible to enable renegotiation, please file an issue against https://github.com/mongoose-os/mbedtls

please provide setup to test it (host name, etc)

Where communities thrive

People

Repo info

Activity