MSPM0G1507: mcuboot port bugs

Tool/software:

We found multiple bugs for the in-SDK mcuboot port, especially when we are defining #define MCUBOOT_SWAP_USING_MOVE 1 in mcuboot_config.h to enable slot swap (no A/B ping-pong switch).

Bugs:

1. assert() issue

In example file (for every project actually): mspm0_sdk_2_02_00_05/examples/nortos/LP_MSPM0G3507/boot_manager/boot_application/flash_map_backend/flash_map_backend.c

#define assert(x)

Doesn't comply with the traditional <assert.h>. Normally, it should proceed if x is non-zero.

Also, I see mixed use in following source codes, such as:

    /* check if read is within bounds */
    assert((write_start_addr + len) > (fa->fa_off + fa->fa_size))

        /* check that the start address is aligned properly TODO: remove*/
        assert((write_start_addr % 4) == 0)
        /* check that the length written is in 32 bits */
        assert((len % 4) == 0)

The 1st one meet your local define expectation, but 2nd and 3rd don't.

2. Unaligned access

Same file, in function flash_area_write()

DL_FlashCTL_programMemoryBlocking() expecting uint32_t * as input data pointer. However, I traced back for all referencing of flash_area_write()

Most of the caller function defined a local buffer as uint_8 array. Unless you use __attribute__((aligned(sizeof(uint32_t)))), it doesn't guarantee the address align to 4.

Probably only boot_write_enc_key() can get rid of it since the structure member offset satisfy the 4-byte-aligned.

Solution: If want to keep efficiency, please change all the caller function to make sure they aligned to 4 using attribute or define as uint32. Otherwise, need to make no assumption of the address is 4 aligned.

Also, a suggestion for SDK:

Can you please change all function that request data input read-only access with prototype const?

e.g.,

bool DL_FlashCTL_programMemoryBlocking(FLASHCTL_Regs *flashctl,
    uint32_t address, uint32_t *data, uint32_t dataSize,
    DL_FLASHCTL_REGION_SELECT regionSelect)

use const uint32_t *data is more proper declaration. This avoid our user to force convert the pointer from read-only(RO) to RW. Since some pointer, by nature, is coming from flash itself.

This enforce the "least privilege" rule of thumb.