Hi Raphael,
for the native-stuff you have to ask Ludwig for the specifics as to of why,
but most of the hosts system's implementation of standard functions are
wrapped. I think this was because our POSIX interface would otherwise
colide with the system's POSIX interface. As for the other boards
Hi,
On Thu, Jan 22, 2015 at 10:56:22AM +0100, Martine Lenders wrote:
for the native-stuff you have to ask Ludwig for the specifics as to of why,
but most of the hosts system's implementation of standard functions are
wrapped. I think this was because our POSIX interface would otherwise
colide
Hi :-)
I have trouble making sense of this - could you please elaborate a
bit? (This is what I read: If there is an error in the firmware update
code it might not work.)
This is what i mean.
I guess that is to be expected. If the firmware update contains an error
it might not work.
To add
If I may throw up a ball.
I think we should only define and specify a secure OTA protocol and
leave it up to the implementation if an external flash memory is used
for saving the image or an internal. For the OTA protocol this is not
relevant and we should not limit the implementation by
Hello Ludwig,
Am 22.01.2015 um 10:50 schrieb Ludwig Ortmann:
Hi,
On Thu, Jan 22, 2015 at 10:20:47AM +0100, Frank wrote:
it's possible to brick the device when flash code crashes every time
when it writes a new image. Then we have an corrupt image and an non
working image.
I have trouble
