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