summaryrefslogtreecommitdiff
path: root/fw/app/src
AgeCommit message (Collapse)Author
12 hoursfw: app: http: Set settings content type to text/jsonxengineering
12 hoursfw: app: settings: Avoid external arrayxengineering
3 daysWIP: fw: app: settings: Temporary fix for SEGFAULTxengineering
3 daysfw: app: settings: Minimize changes for SEGFAULT fixxengineering
The core issue is that JSON_TOK_STRING as last argument to JSON_OBJ_DESCR_PRIM issues the SEGFAULT. Using JSON_TOK_NUMBER instead is the minimal change to avoid the SEGFAULT temporarily. Obviously this leads to nonsense output since the string is printed out as number.
3 daysWIP: fw: app: Fix empty HTTP responsexengineering
This was caused by a body_len set to 0 because of changed semantics in the return value of settings_to_json().
4 daysWIP: fw: app: Fix SEGFAULTxengineering
TODO: Only JSON numbers seem to be encodable. Strings lead to SEGFAULT TODO: For some reason the encoded string is not part of the HTTP response.
4 daysWIP: fw: app: Encode settings with JSON libxengineering
TODO: SEGFAULT in json_escape_internal (grrrrr)
4 daysfw: app: http: Add working GET /settings.jsonxengineering
5 daysfw: app: http: Add dummy GET /settings.jsonxengineering
5 daysfw: app: syslog: Stop supporting CONFIG_LOG_BACKEND_NET_SERVERxengineering
From now on the mixed format with IP and port is not supported. The settings system should keep them separate and first only the IP is configurable. Supporting this Kconfig option too is annoying and not necessary.
5 daysfw: app: syslog: Put only IP into syslog/target/ipxengineering
The old format contained `[<ip>]:<port>`. Nevertheless the format should be as strict as possible. Thus only the IP is used in the setting.
5 daysfw: app: syslog: Implement commit targetxengineering
5 daysfw: app: syslog: Make target IP configurablexengineering
5 daysfw: app: Enable settings with NVS backendxengineering
9 daysfw: app: Re-design web pagexengineering
This enables simple.css also for the device-hosted website and restructures the HTML a bit.
2025-04-02fw: app: Fix native_sim buildxengineering
To reduce the number of Kconfig options the network hack was added two both boards - the native_sim and nucleo_f767zi one. It reboots the device if the network connection cannot be established since this is a known bug of the nucleo board. Nevertheless it seems that for the native_sim board this command is not defined. Since it is a Linux application this makes somehow sense. This commit introduces the boolean Kconfig option `IOT_CONTACT_NETWORK_HACK` which is only enabled for the nucleo board fixing the native_sim build.
2025-03-30fw: app: update: Finish first HTTP PUT /updatexengineering
This adds marking the application firmware image in the secondary slot for a permanent update and rebooting the device. It is a known bug that the corresponding HTTP request is never properly closed since the device reboots while handling the request. Nevertheless the current state works and enables remote updates.
2025-03-30fw: app: update: Write uploaded image to flashxengineering
This write the received firmware image data to the secondary MCUboot slot. This prepares an update. With the MCUboot shell it can be applied with: mcuboot request_upgrade permanent kernel reboot If the signature is valid the device will permanently update to the new application firmware. Otherwise it will refuse the new image and boot the old one.
2025-03-30fw: app: update: Add data rx on HTTP PUT /updatexengineering
This implements a HTTP handler capable of receiving the full data of the firmware image upload. The data is not handled at all and thus not written to flash. This is just an incremental step towards successful firmware image upload to the secondary MCUboot slot.
2025-03-30fw: app: update: Add source file and HTTP 204 handlerxengineering
This adds the HTTP PUT /update handler which just returns HTTP 204 No Content. This is the minimal first step towards a working /update handler.
2025-03-30fw: app: Reboot in case of no networkxengineering
Because of an issue likely related to hardware design on the nucleo_f767zi board (see issue [1] for details) the firmware should reboot in case network access cannot be established after 4 seconds. This makes the firmware more robust at the moment. As soon as iot-contact hardware without this issue exists the behavior can be changed again. [1]: https://github.com/zephyrproject-rtos/zephyr/issues/77794
2025-03-26fw: app: Move application firmware code herexengineering
This makes the structure of the `fw` folder more clear and separates application-related code from bootloader- or rtos-related code.