Using unique DCT with external filesystem

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi, I'm running into issues loading a custom DCT into internal memory. I am using the platform patch seen here Patch to put firmware on external flash

I am successfully able to do the following (via the command line):

  • generate unique DCT
  • download the bootloader
  • download a temporary DCT
  • download my application
  • download FR_APP to sflash
  • download "factory_reset" DCT_IMAGE to sflash
  • download resource filesystem to sflash
  • download apps LUT to sflash


Then, upon reset, my temporary application uses wiced_dct_restore_factory_reset() to pull the unique DCT into memory. Although it feels clunky, this works. I would really prefer to be able to download a unique DCT directly into internal flash that can be used during our testing procedure at manufacturing. Then, when the testing is complete, it will restore the factory reset DCT and be ready to ship.


In trying to accomplish this, I completed the above steps and then downloaded the factory_reset DCT using:

%FTDI_EXE% -f %JTAG_CFG% -f %MCU_CFG% -f %FLASH_CFG% -c "flash write_image erase %UNIQUE_DCT_ELF%" -c shutdown >> build/openocd_log.txt


I can see the unique dct is successfully loaded in memory at 0x08004000, but when it runs, it reaches the assert in wiced_init()->wiced_core_init()->wiced_platform_init()->platform_filesystem_init(). This is due to fs_header.magic_number and fs_header.version being wrong...

I'm truly at a loss as to why this is happening, and why it only happens when I try to use my unique DCT. How could downloading a unique DCT to internal flash mess up the filesystem on external flash? Perhaps there is something missing in my custom DCT that is supposed to be there to links back to the filesystem?

Any guidance or suggestions would be very much appreciated.

Will

0 Likes
1 Solution
Anonymous
Not applicable

Ok I understand a little better now. The dct_header fields are populated in the way they are because of my app's factory_reset_dct.c file. I used demo/temp_control/factory_reset_dct.c as a template for mine, so it currently looks like this:

    /* DCT Header Section */

    .platform.dct_header.write_incomplete     = 0,

    .platform.dct_header.is_current_dct       = 1,

    .platform.dct_header.app_valid            = 1,

    .platform.dct_header.mfg_info_programmed  = 1,

    .platform.dct_header.magic_number         = BOOTLOADER_MAGIC_NUMBER,

    .platform.dct_header.load_app_func        = NULL,

The fields full_size, used_size, boot_detail, and apps_locations are not explicitly specified so they're being set to NULL.

I was able to achieve my goal by copying the dct_header.apps_locations part of WICED/internal/dct.c into my app's factory_reset_dct.c. The unique DCTs now appear to be correctly recognizing the filesystem.

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

Hi,

The DCT does include information about location of different applications in external flash. These include  external firmware and the FR_APP and other binaries located in the external flash. To understand more have a look at the WICED/platform/included/platform.h. , mainly the apps_location entry in the dct header structure. When building your system and setting the what files goes to the external flash, those entries get  filled with correct values by the build system.

So when looking at your DCT make sure that those parts are not changed between your temporary and unique DCT (as long as you didn't write in to any of those external files).

Is there any reason those entries could be different between your two versions of DCT?

Regards,

Bassem

0 Likes
Anonymous
Not applicable

Hi Bassem,

I had overlooked that. The dct header portion of my unique DCT is missing some information. It only correctly contains the following:

        char write_incomplete;

        char is_current_dct;

        char app_valid;

        char mfg_info_programmed;

        unsigned long magic_number;

The fields full_size, used_size, boot_detail, and apps_locations are all empty, so that is surely the issue.

I'm using 3.1.2 and couldn't find a way to generate unique DCT's so I used the "patch" found at the bottom of Re: factory_reset_dct not working . The wiced_factory_reset.mk is modified from the version found in 2.4, so it must not be filling in the fields properly.

I can see now that wiced_dct_restore_factory_reset() copies my unique DCT from the external flash but maintains correctness in the dct_header, and that is how I was able to get it to work.

So I guess my questions now are, how can I modify my wiced_factory_reset make file to include this information in the unique generated DCT? Where in the make system is the correct app DCT being generated? Is the apps location info stored in the config.mk file?

Thanks!

Will

0 Likes
Anonymous
Not applicable

Ok I understand a little better now. The dct_header fields are populated in the way they are because of my app's factory_reset_dct.c file. I used demo/temp_control/factory_reset_dct.c as a template for mine, so it currently looks like this:

    /* DCT Header Section */

    .platform.dct_header.write_incomplete     = 0,

    .platform.dct_header.is_current_dct       = 1,

    .platform.dct_header.app_valid            = 1,

    .platform.dct_header.mfg_info_programmed  = 1,

    .platform.dct_header.magic_number         = BOOTLOADER_MAGIC_NUMBER,

    .platform.dct_header.load_app_func        = NULL,

The fields full_size, used_size, boot_detail, and apps_locations are not explicitly specified so they're being set to NULL.

I was able to achieve my goal by copying the dct_header.apps_locations part of WICED/internal/dct.c into my app's factory_reset_dct.c. The unique DCTs now appear to be correctly recognizing the filesystem.

0 Likes