What is the memory map for the M-SoM (Muon)?

Firmware Device OS
1

In my application, I do the following on startup:

  • calculate CRC32 of the present region of user application flash
  • compare to retained (eeprom) CRC from previous runtime
  • if there is a difference, activate the “DFU boot” app flag (my app does certain memory mapping migration chores etc in response to this)

This worked fine on the Boron, but I am not sure what the memory map is for the M-Som (Muon) that I am trying to port this functionality to (if I use the Boron memory map values to try and calculate this CRC I will get a bus fault):

//Check the linkapp CRC.  If it's different, we need to reset sram also!
unsigned int linkapp_crc = 
    compute_CRC32((uint8_t*)(LINKAPP_MEMORY_ADDR_START), LINKAPP_SECTION_SIZE, 0, true, &crc32_mpeg2);
if(linkapp_crc != sram.linkapp_crc && sram.linkapp_crc != 0){
    #ifdef VERBOSE_RETAINED_VARS
    myLog.warn("New LinkApp CRC!");
    #endif
    reset_sram(__LINE__);
    recall_eeprom();
    linkapp_flags.dfu_boot = true;

    //Run firmware migrations
    #if SRAM_MAP_VERSION <= 0xC0DE0002
    sram.e.hc3_primary_gnd_resistance_mohm = 0;
    #endif
}
sram.linkapp_crc = linkapp_crc;

Here are the defines:

/**========================================================================
 **                            PLATFORM-SPECIFIC
 *========================================================================**/
#if (PLATFORM_ID == PLATFORM_BORON)
    #define LINKAPP_SECTION_SIZE KB(256)
    #define LINKAPP_MEMORY_ADDR_START  0xB4000
#elif (PLATFORM_ID == PLATFORM_MSOM)
    #define LINKAPP_SECTION_SIZE KB(256)
    #define LINKAPP_MEMORY_ADDR_START  0xD0D00 //What is this supposed to be?
#endif

Note that the Boron has a well defined memory map published here:

… but the M-SoM datasheet does not have any section called “memory map”…

So, ultimately the question boils down to: how can I evaluate if my app has a new firmware since previous check?

2

Yes, you can do that, but it's tricky on RTL872x devices. The reason is that the user firmware binary is right aligned by sector, which is to say it goes at the end of the user firmware slot, and thus the start address will vary depending on the size of the binary.

Fortunately, a OTA binary incudes the module start address and module end address in the .bin file. It also includes a fixed header and trailer block. The binary-version-reader is a node library to decode the header, but it's pretty straightforward and you can decode it just by reading the correct offsets in the binary.

However, if you're starting from the data that's already on the device, you'll need to read the trailer block, which will be a known address. From that, you can find the length, which will get you to the start address. The format of these blocks is the same as what the binary version reader uses.

These are the adddresses for the user part on all RTL872x devices:

module_bounds_t module_user = {
    .maximum_size = 0x180000, // 1.5MB
    .start_address = 0x08600000 - 0x180000,
    .end_address = 0x08600000,
    .module_function = MODULE_FUNCTION_USER_PART,
    .module_index = 1,
    .store = MODULE_STORE_MAIN
#if HAL_PLATFORM_NCP
    ,.mcu_identifier = HAL_PLATFORM_MCU_DEFAULT
#endif
    ,.location = MODULE_BOUNDS_LOC_INTERNAL_FLASH, // XIP
    .flags = MODULE_BOUNDS_FLAG_FIXED_END_ADDRESS
};