How does an application read out its own EBL header tags?

Some applications may wish to read their own EBL header tags, as this contains useful data such as a build timestamp and platform settings for the build, which could be used to check for a potentially incompatible image or a recently updated image, or simply provide information to a querying device upon request. (For customers using the Application Bootloader, with its dedicated download space, note that these instructions pertain to the current image’s EBL header, not the image residing in the download space.)

Since the EBL header is contained at the end of the STKIC (Stack Info Constants) segment of the EM250’s memory map, which precedes the application’s own CODE segment, a subroutine like the following should work for extracting the EBL header tag out of the image currently running in main flash:

// Try to read out our own EBL header by extracting the last portion of the flash 
// segment just before our own CODE segment.
// See em250-ebl.h for EBL header structure definition
// If return status is EMBER_SUCCESS, EBL header is populated;
// else, the status will indicate some problem reading flash
EmberStatus readAppHeader( eblHdr_t *appHeaderPtr )
{
  return halInternalFlashBlockRead( 
    (PROG_CODE_BASEW – DATA_TO_PROG(sizeof(eblHdr_t), 
    appheaderPtr,
    DATA_TO_PROG(sizeof(eblHdr_t)));
}

This uses the same macro symbols as the compiler is using to compute the memory map, so it should work equally well regardless of which bootloader (if any) you’re running on the device in question.

Once you have the whole EBL header struct, you should be able to inspect whatever bits of it you care about. Note that the timestamp here is in UNIX “epoch-based” notation, meaning that the value represents the number of seconds since the “Epoch” (beginning of UNIX era) of January 1, 1970. See http://www.epochconverter.com for a web-based utility that converts these epoch-based timestamps back to readable YY/MM/DD hh:mm:ss timestamps.

Note that this code is only applicable to the EM250 platform, as other architectures use different defined constants to reference their own memory map.