stop the selSec from being applied twice to lastSector

[jpbland1]

ZD 19133

I found a mistake in the update trigger code where the selSec for nvm writeonce was being subtracted from the base address and then subtracted again for the erase operation. We need to add a test with a fullsize update image that would have been corrupted by this mistake. I've previously tried and failed to make a full size image test in test.mk @danielinux I could use advise or help on this

[danielinux]

Looks it's the right fix now (edit: tested unsuccessfully. See below). Let's wait for feedback on ZD19133

[danielinux]

@jpbland1
Here is a manual test to reproduce the issue:

diff --git a/test-app/app_sim.c b/test-app/app_sim.c
index e118e5a9..2cdf8e28 100644
--- a/test-app/app_sim.c
+++ b/test-app/app_sim.c
@@ -112,11 +112,20 @@ int do_cmd(const char *cmd)
     /* wrong command */
     return -1;
 }
+#define FILL_APP_PARTITION
+#ifdef FILL_APP_PARTITION
+#define FILLER_SIZE (105 * 1024)
+static volatile uint8_t filler_data[FILLER_SIZE] = { 0x01, 0x02, 0x03 };
+#endif
+
 
 int main(int argc, char *argv[]) {
 
     int i;
     int ret;
+#ifdef FILL_APP_PARTITION
+    filler_data[FILLER_SIZE - 1] = 0xAA;
+#endif
 
     hal_init();

If you add an arbitrary amount of bytes to the application to grow past the third-last sector, you will see it fail with the NVM workaround. I've used 105KB to go over the limit. With config/examples/sim-nvm-writeonce.config we have sector size 4K and partition size of 0x40000 so the third-last sector starts at 0x40000 - (3 * 0x1000) - 0x100 = 0x3CF00 aka 249600.

To trigger the bug with NVM fix, you should get an application between 249600 and 253695 bytes, e.g.:

$ cp config/examples/sim-nvm-writeonce.config .config
$ make clean && make test-sim-internal-flash-with-update
[...]
Output image(s) successfully created.
	Added        64984 bytes at 0x00000000 from wolfboot.bin
	Added        66088 bytes of 0xff fill
	Added       250216 bytes at 0x00020000 from test-app/image_v1_signed.bin
	Added        11928 bytes of 0xff fill
	Added       250216 bytes at 0x00060000 from test-app/image_v2_signed.bin
	Added        11928 bytes of 0xff fill
	Added         4096 bytes at 0x000a0000 from erased_sec.dd

^ Application size is in the desired range

$ ./tools/scripts/sim-sunnyday-update.sh
Failed update (V: 1)

Update fails with NVM workarounds, succeeds otherwise, or if you make the application smaller than 249600 by reducing the filler size.

Unfortunately, I've tested the current proposed change in this branch and does not seem to fix the issue.

[danielinux]

I've made a quick manual test and it does not seem to fix the reported issue. Please see comments.

[jpbland1]

Removed the sector straddle realignment code, I would need to look through the log but either the address calculation was updated not to require the realignment or the realignment was only required because of the double subtraction I already fixed. Either way it's passing the manual test max size test. We need to change all the update tests to use a max size image to prevent regressions on this. My initial thought was to build the image once normally, subtract the image's size from the max size and then rebuild the image with that many filler bytes but I couldn't get it working inside of test.mk and I don't know where else you would implement it that would apply to every test, ideas on this are appreciated.

[MulattoKid]

Seems to fix the issue reported in ZD19133 - thanks!