cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

hiko_4316286
New Contributor

Since the following error occurred when the program was started, the problem has been resolved by taking the action described in [1].

  ************************************************** **

  ** ERROR: WLAN: could not download clm_blob file

  ** FATAL ERROR: system unusable, CLM blob file not found or corrupted.

  ************************************************** **

[1]Details of support

   When the Wi-Fi FW was updated, an error occurred due to an inconsistency between the placement of memory sectors managed by the application and the placement of external Flash.

  "RESOURCES_LOCATION ? = RESOURCES_IN_WICEDFS", the external Flash could not be updated, which resulted in the inconsistency.

   Changed the setting to "RESOURCES_LOCATION ? = By changing the configuration to "RESOURCES_IN_DIRECT_RESOURCES", the error will not occur.

   Because the build error occurred when the above settings were changed, added the following settings so that the LUT can be written to the external Flash.

   -----

   /tools/makefiles/standard_platform_targets.mk

  

   #ifeq ($(RESOURCES_LOCATION),RESOURCES_IN_WICEDFS)

   download: $(STRIPPED_LINK_OUTPUT_FILE) display_map_summary download_bootloader $(if $(findstring no_dct,$(MAKECMDGOALS)),,download_dct) APPS_LUT_DOWNLOAD

   #else

   #download: $(STRIPPED_LINK_OUTPUT_FILE) display_map_summary download_bootloader $(if $(findstring no_dct,$(MAKECMDGOALS)),,download_dct)

   #endif

   -----

[2] Confirmation

   There is a confirmation of the behavior when the software with "RESOURCES_IN_DIRECT_RESOURCES" is updated against the module with "RESOURCES_IN_WICEDFS" set.

   It works with the current configuration, but I'm not sure how WICED affects it, so I'm asking.

1. If you set "RESOURCES_IN_DIRECT_RESOURCES", the filesystem will be included in the application and no inconsistency will occur?

2. Update "RESOURCES_IN_DIRECT_RESOURCES" software to "RESOURCES_IN_WICEDFS" module.

  If I update the software again in this state, is it correct that "FR_APP" will not be destroyed when updating to APP0 because the LUT of the external flash will not be changed?

0 Likes
15 Replies
MuraliR_36
Moderator
Moderator

hiko_4316286

1. If you set "RESOURCES_IN_DIRECT_RESOURCES", the filesystem will be included in the application and no inconsistency will occur?

--> Re: How can I flash the wifi firmware at a certain address on the internal flash ? This thread should give you a fair idea and there should be no issues. Again, the best way of being sure is by testing this out with your application.

2. If it is set as RESOURCES_IN_DIRECT_RESOURCES, I don't think the FR_APP and the DCT image will get downloaded since these are programmed to go to the external flash and I think there will be a build/download error.

Now if you download the FR_APP once when you have set RESOURCES_IN_WICEDFS and ensure that you don't meddle with the location as to where the FR_APP has downloaded, It should remain there itself. The content of the FR_APP has nothing to do with the LUT as the latter just points to where the FR_APP is there.

Thanks

0 Likes
hiko_4316286
New Contributor

Thanks for the answer.

Updated with firmware created with "RESOURCES_LOCATION ?= RESOURCES_IN_DIRECT_RESOURCES" for the environment built with "RESOURCES_LOCATION?= RESOURCES_IN_WICEDFS"

  At this time, there is a difference in the placement of external Flash, but the filesystem is included in the application and therefore there is no error due to inconsistency, is it correct to recognize this?

I am aware that the LUT refers to the location where the downloaded firmware is saved when writing to APP0.

  In this case, even if there is a difference in the arrangement of the external Flash as described above, won't the destruction of other data by writing to AAP0 occur?

  Also, reading FR_APP will not be a problem?

0 Likes
MuraliR_36
Moderator
Moderator

hiko_4316286

At this time, there is a difference in the placement of external Flash, but the filesystem is included in the application and therefore there is no error due to inconsistency, is it correct to recognize this?

--> If you have done the required tests and don't seem to face any errors, then I think you are good to go.

In this case, even if there is a difference in the arrangement of the external Flash as described above, won't the destruction of other data by writing to AAP0 occur?

--> Can you please elaborate as to what you mean by other data? When the Resources location is set to RESOURCES_IN_DIRECT_RESOURCES, this takes care placing everything inside the internal flash and there is no need to do anything additional.

Also, reading FR_APP will not be a problem?

--> Can you please elaborate this? The FR_APP gets loaded in the external flash. So as far as you don't meddle with it, I think there won't be any issues.

Thanks

0 Likes
hiko_4316286
New Contributor

Thank you for your confirmation.

In this case, even if there is a difference in the arrangement of the external Flash as described above, won't the destruction of other data by writing to AAP0 occur?

--> Can you please elaborate as to what you mean by other data?

The following data is stored in the external Flash.

(When set to "RESOURCES_LOCATION ? = RESOURCES_IN_WICEDFS")

- Application LUT

- Factory Reset Application

- DCT_IMAGE

- FileSystem Image

Updating the "RESOURCES_LOCATION ?= RESOURCES_IN_DIRECT_RESOURCES" set FW is concerned about whether APP0 will not corrupt the above data.

Also, reading FR_APP will not be a problem?

--> Can you please elaborate this?

Updated FW set "RESOURCES_LOCATION ?= RESOURCES_IN_DIRECT_RESOURCES" against a module of "RESOURCES_LOCATION ? = RESOURCES_IN_WICEDFS" configuration

If you compile with the above settings, the external Flash will be arranged differently in each case, but the external Flash cannot be updated in the update

After the update, "RESOURCES_LOCATION ?= RESOURCES_IN_DIRECT_RESOURCES" software will work with "RESOURCES_LOCATION ? = RESOURCES_IN_WICEDFS" external Flash deployment

In this state, I'm wondering if there is a problem if you try to read FR_APP

*The LUT of the external Flash has not changed and I believe that the external Flash data can be read.

0 Likes
hiko_4316286
New Contributor

If you find out anything, please give us an answer.

0 Likes
MuraliR_36
Moderator
Moderator

hiko_4316286 I tried out some tests which I should have done initially but here are my observations. I tried loading the code using RESOURCES_IN_DIRECT_RESOURCES using STM32F411 based 43438 and the OTA_fr application didn't seem to fit inside the internal flash. Can you do a sanity check and confirm if this is the case even in your 4343 based setup? If it is so, then from an application point of view, this discussion would be for void.

0 Likes
hiko_4316286
New Contributor

The FW when set to "RESOURCES_IN_DIRECT_RESOURCES" is 912 Kbytes.

The internal Flash of the STM32F411 is 1Mbyte, so writing was possible.

The FW of 912Kbyte is set in FR_APP.

0 Likes
hiko_4316286
New Contributor

Sorry, the update was lost, so I'll post it again.

Additional information.
This is the compile-time log.
-----
Downloading Bootloader ...
Building apps lookup table
No changes detected

Downloading DCT ...
Download complete

Downloading FR_APP build/Module_board-ThreadX-NetX_Duo/../../apps/ComboModule/FR_APP.stripped.elf at sector 1 address 4096...
Downloading DCT_IMAGE build/Module_board-ThreadX-NetX_Duo/../../apps/ComboModule/DCT_IMAGE.stripped.elf at sector 124 offset 507904 size 3...
Downloading apps lookup table in wiced_apps.mk ... build/Module_board-ThreadX-NetX_Duo/APPS.bin @ 0x0000 size
Downloading Application ...
No changes detected
-----

0 Likes
hiko_4316286
New Contributor

Is there any other information I should contact you about?

0 Likes
hiko_4316286
New Contributor

When we checked the operation here, there was a problem that "DCT_WIFI_CONFIG_SECTION" disappeared.
The factory data did not have "DCT_WIFI_CONFIG_SECTION", so it disappeared.

This problem can be solved by reconfiguring the DCT.
And this problem seems to be the original problem of the factory processing, not the problem caused by this fix.

Is there anything else that could be a problem with the fix that we have addressed?
Or will it work fine with this change?

 

0 Likes
MuraliR_36
Moderator
Moderator

@hiko_4316286 I'm a bit confused. has the issue been resolved?

If not can you please put up a list of points with which you still need help on?

0 Likes
hiko_4316286
New Contributor

The following are some of the questions we have.

(1) For environments built with "RESOURCES_LOCATION? = RESOURCES_IN_WICEDFS", FR_APP and filesystem are separated.
(2) For the environment built with "RESOURCES_LOCATION? = RESOURCES_IN_DIRECT_RESOURCES", FR_APP and filesystem are combined.

When the status of the external Flash is (1), if you update APP0 with the data of (2), won't the data of FR_APP be destroyed?
My assumption is that there will be no problem because the LUT of the external Flash is arranged as (1).

0 Likes
hiko_4316286
New Contributor

I have picked up a question.
Is it possible to answer with this content?

0 Likes
hiko_4316286
New Contributor

Please respond with any information you have.

0 Likes
MuraliR_36
Moderator
Moderator

1. Yes

2. I don't think the FR_APP and the filesystem.bin are combined.

Yes, there should be no problem since the FR_APP should be at  a separate location.

0 Likes