New option: skip to next image via GPIO

[DutchFox2]

Hi Richard,

I have added a new feature to rBoot, because the existing GPIO feature didn't suit my needs. It might be useful to others as well.

Background: I am using rBoot with 2 slots. Firmware updates (downloading and flashing) are performed by the user program, where the active program in slot 0 will flash into slot 1 or vice versa.
In the situation where flashing was succesful (ROM checksum is ok), but the program itself contains a bug, rBoot will keep booting into that new ROM image. If the networking or firmware upgrade code is broken, I'm stuck.
The 'normal' GPIO functionality is no solution here, because it can only boot into a predefined slot. If this slot happens to contain the 'broken' firmware, it doesn't help.
The new option uses GPIO to simply mark the current slot as 'invalid', and lets the existing code search for an other ROM to boot from. In my case, it will find the previous firmware in the other slot, which can be used to re-flash a new (hopefully fixed) image.

Commit f04392b contains the new option mentioned above.
In commit 3c68cc9 I have separated the reading of the GPIO pin from configuring it as an input. In my opinion, the pin should be set as input as early in the boot process as possible, to prevent large currents when the pin is also driven externally. Furthermore, once the pin is configured as an input, there is a lot more time for the voltage at the pin to stabilize at the required level before the pin state is read back.

I couldn't convince Github to exclude bb7421d from the pull request, please ignore it.

Cheers,

Matthijs

[raburton]

Could you please take a look at the 'test' branch. I've implemented your request (slightly differently), please check it meets your needs before I merge with master.

[DutchFox2]

On 03-09-16 14:05, Richard Antony Burton wrote:

Could you please take a look at the 'test' branch. I've implemented
your request (slightly differently), please check it meets your needs
before I merge with master.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#19 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ARRvJZ01AnYfsIi-DEUZKsB_GAjuVOfhks5qmWJsgaJpZM4JjCQP.

Thanks Richard, I'm glad that you liked the 'skip to next image' idea.

I have looked through the diff on Github, your implementation looks fine
to me. Of course, mine was a bit minimalistic (to keep the maintenance
effort of a separate branch/patch low), yours is better integrated with
the rest of the code.

I'm afraid that I will not have the opportunity to do a real test in my
esp8266 project for at least the next few weeks. However, looking at
just the code I'm pretty confident that it will fit my application. I'll
leave it up to you whether you prefer to wait for a real test first, or
to merge the test branch into the trunk asap.

One thing which comes to mind right now is: would other users be helped
with an extra compile-time option, so they can choose between skipping
to the 'next' (/romToBoot = romconf->current_rom + //1/) or the
'previous' (/romToBoot = romconf->current_rom - //1/) ROM?
In my situation (with only 2 slots) it doesn't matter, but I can image
that in case of multiple ROM slots, someone would like to skip back to
the previous one instead of skipping forward to the next one.
Of course, one could also solve the same problem by inverting the
direction in which he flashes new ROMs: if the newest ROM is flashed
into /'current-1'/ instead of/'current+1/', then skipping to the 'next'
ROM is actually the previous (most recent) working ROM.

Kind regards,

Matthijs