in application programming (ethernet), e.g. STM32

[rjmaris]

Upon some investigation, I found nxp-related resources for IAP. But without greater effort I can't figure out whether it fully relies on bootloader built-in resources.
More general: it seems that IAP is yet not covered by Zephyrproject in the sense of a platform independent resource.

Specifically, I'm targeting STM32, ethernet-based AIP.
For the STM32 family, code exists to allow IAP over Ethernet (for STM32Cube) as described in UM1709. Here, two possible solutions are provided: either TFTP or HTTP, in both cases on top of lwIP TCP/IP stack.
I'd have to modify the lwIP_IAP code to adapt to the Zephyr IP stack. I'd be happy if anybody would contribute in adaptation/migration effort OR have hints of creating new code that would use Zephyr flash controller resources together with Ethernet usage for binary transfers.

[jukkar]

Not sure what kind of APIs you mean by IAP (In-Application Programming). Zephyr has support for both TFTP and HTTP, and there exists Ethernet driver for stm32, so you should be able to get things done by plain upstream zephyr code. There should be no need to port lwip code to zephyr.

[rjmaris]

Thanks for clarifying things. That'll help to start the right way forward in getting `IAP` via Ethernet done. To be precise: I mean in application programming of (the whole) flash area, what either needs a `firmware update` code running in RAM (with danger of halfway flashed updates) or a custom bootloader code (which is utilized with the STM approach according to their UM1709). The latter requires a certain port pin (e.g. a key) to be active during POR or reset by the application code. In my current project, a 'normal' user key is consciously assigned to a GPIO that serves this (customized) bootloader start function. Momentarily this allows IAP through USB, which is part of the standard bootloader code. As soon as I have a complete picture, I'm going to implement the custom bootloader code in parallel with the accompanying zephyr code (that should then merely trigger the custom bootloader upon issuing a bootloader directed reset) or without zephyr code using the specific keypress on power down). Just by writing this, I'm getting aware that the custom bootloader code DOES the whole IAP-process and as such, would depend on self-contained Ethernet code e.g. based on minimal lwIP-resources. Insofar, at least part of the solution still lies in code specific to STM, not generic zephyr code. I just remind myself that former Luminary (now TI) `LM3S` Cortex micros precisely support Ethernet `IAP` in the default bootloader. I'll dig in the details of the STM approach and then return here after having the picture complete.

[rjmaris]

I have managed to obtain the native ST-code and built it (for the demo target). With simple TFTP-server only (the build can also be targeted to http), the whole binary eats approx. 112 kBytes.
The bootloader is NOT sort of an extension to the built-in bootloader, and hence 128 kB must be reserved as "bootloader" area (hence any desired GPIO can be assigned as an IAP invocation trigger).

Considering that my whole target application including Ethernet and small display control is just over 150 kB, I'm thinking about porting the IAP code to Zephyr, and then apply its own Ethernet stack and TFTP resources. This would then open the door to create a virtually platform independent IAP code that runs from the default flash starting address, while the target application should start at an offset of 128 kB (or 64 kB if the binary size would be substantially smaller then the original code).