1 reply
the chip thinks it's unhealthy
and refuses operations
if power cycle doesn't do it, then i guess it's the chip
never seen this happen before, but that's my guess
@hoffmann-m ^^
Hi, I'm trying to implement custom OTA mechanism for ESP32 using ESP-IDF bootloader application rollback feature. But when I enable CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE=y sdkconfig option the build fails. I looked into docker container to esp-idf
components/bootloader_support/include/esp_flash_partitions.h and it seems that necessary enum values are enclosed in #if 0 enum ... #endif. But in official ESP-IDF sources the needed enum is not enclosed in #if 0 #endif block. Is there some way to easily use this ESP-IDF feature along with rest of mongoose features(except mongoose OTA feature). Thank you.
it's entirely possible that some features won't work
what are you looking for in appt rollback? maybe our own version (commit_timeout) will work for you
IDFs OTA mechanism and functions API are really good documented... I was thinking about using mgos/ota-common module, but i didn't found any documentation on how to use it, also I didn't found any example or README in ota-common repository. Everything regarding mgos/ota-common seems closed-source. That's the reason why I tried ESP-IDF OTA, but as I wrote there are surprises in your fork of IDF 🙂
Hi, I am trying to connect to a mqtt server hosted locally in a raspberry pi from my esp32. Is it possible to connect to the mqtt server using
raspberrypi.local domain name using mdns?
hey guys,I am facing issue with downloading file to ESP32 via http.
I am using this example
https://github.com/mongoose-os-apps/http-fetch
when I am trying with flash encrypted ESP32 if the file size is small (e.g 10-15kB) ,it is fine and downloaded with out any problem, but if the file is bit bigger (e.g 35-45KB) wdt is triggered when writing the chunk.
on the other hand is I am trying with non-encrypted flash esp32 all the files are downloading and writing to file with out any issue.
_
I am using this example
https://github.com/mongoose-os-apps/http-fetch
when I am trying with flash encrypted ESP32 if the file size is small (e.g 10-15kB) ,it is fine and downloaded with out any problem, but if the file is bit bigger (e.g 35-45KB) wdt is triggered when writing the chunk.
on the other hand is I am trying with non-encrypted flash esp32 all the files are downloading and writing to file with out any issue.
_
Read the docs regarding configuration https://mongoose-os.com/docs/mongoose-os/userguide/configuration.md
@DrBomb
mgos_sys_config_set_rpc_udp_listen_addr("udp://0.0.0.0:1234");
char *err = NULL;
save_cfg(&mgos_sys_config, &err);
printf("Saving configuration: %s\n", err ? err : "no error");
free(err);I have done this way and in logs it prints saved to conf9.json and no error
But when I ran this mos call --port udp://192.168.43.107:1234/ Sys.GetInfo command it doesn't work.
After I set it using mos config-set , and call the rpc over udp that works. Am I missing something here ??
@cpq it looks as though the server certificate has expired at mongoose-os.com??
@abhibhatia98
rpc.udp.listen_addris for listening to the debug output of a mos device FROM a remote machine without serial connection. It sounds like what you are doing is send RPC command TO a mos device? In which case you need the RPC libs
@gadget-man, Actually I didn't get your Comment, so explaining issue I am facing again:-
So I am trying to setup rpc.udp.listen_addr To do so 2 approaches are here
- By
mos config-set rpc.udp.listen_addr=udp://0.0.0.0:1234
After this I callmos call --port udp://IP:1234/ Sys.GetInfoget the response back with device packet. - By Program save_cfg method(Code used shared in previous comment)
After this I callmos call --port udp://IP:1234/ Sys.GetInfo,it get fails withError: context deadline exceeded. After that I reboot the device try same it gives response. So is it like that save_cfg method requires reboot or something else I am missing ?
After saving the config, what happens if you call
mos config-get rpc.udp.listen_addr?
Oh, but I see you did reboot it, my bad
Then, I would suggest checking the value back with
mos config-get
Hi, is there some documentation how to implement OTA over BT SPP? Or particulary how to use ota-common mongoose module to flash data to next partition and set next partition as boot partition. Thanks.
Hi @janko.valiska:matrix.org I don't know if you're aware. But while most mongoose-os is open source. The OTA sections of it is cesanta's paid product. Their OTA package is only distributed as binaries with restrictions on where the updates can be applied from unless you have the paid versions
So using the ota-common libraries I think might be a moot point for you
That said. I believe the method
OTA.Write is not locked on the binaries, and you could potentially use it to write into the second partition with the loopback RPC
you can use them over BLE GATTS through rpc-gatts library
the approach is simple - OTA.Begin, OTA.Write the zip data (in chunks, of course), OTA.End
Thanks for reply and useful information. I'm curious... is it possible to invoke RPC call directly from code? I want use BT SPP protocol to transfer FW image/zip. So i need somehow execute rpc-service-otas serice calls (OTA.Begin/Write/End) when the data is received from SPP serial interface.
Aaa, probably I should use: rpc-loopback. Am I right?
@DrBomb
@abhibhatia98 The device will need to be rebooted after the setting is changed. The address is bound to the URI at boot time, so changing the config value will not take effect until you restart the device
I have doing something to overcome manual reboot
- ["restart.pending", "b", true, {"title": "First time restart done or not"}]
if(mgos_sys_config_get_restart_pending())
{
mgos_sys_config_set_restart_pending(false);
mgos_system_restart();
}this cause device continuously rebooting. Do you have ideawhats the issue. I have checked condition works fine when I comment restart method
@rojer: Hi, I'm trying to use rpc-service-ota to perform OTA over BT. After couple of chunks I receive
Request queue overflow from mg_rpc_callf handler. I'm sending chunks of size 256bytes every 2 seconds. What can be the problem?