BCM94343W_AVN wicedfs init fail

Solved

I'm trying to get the snip.scan example running on a BCM94343W_AVN eval board. Every time I try to run I encounter the wiced_assert "wicedfs init fail". I saw a previous posting that had the same problem and it was solved using download_apps instead of just download in the make target. However, this did not solve my problem.

My entire make target command is: snip.scan-BCM94343W_AVN-FreeRTOS-LwIP-debug download_apps

 

What am I missing?

PeterF's picture
PeterF
Moderator(16)

I am not able to reproduce the wiced_assert "wicedfs init fail" you mention (either with- or without- the download_apps make target parameter). 

 

Per the Broadcom WICED forum response that you got from Naren Sankar on this topic however,  

"This assert is ok. You can just skip it or comment it out"

 

Ok, that is straight bizzare that you can not see the assert but I do. What is the return code on the result variable when you hit that line of code?

 

platform_result_t platform_filesystem_init( void )
{
int result;
sflash_handle_t sflash_handle;
if ( fs_init_done == 0)
{
init_sflash( &sflash_handle, 0, SFLASH_WRITE_ALLOWED );
if ( wiced_framework_app_open( DCT_FILESYSTEM_IMAGE_INDEX, &fs_app ) != WICED_SUCCESS )
{
return PLATFORM_ERROR;
}
result = wicedfs_init( 0, read_callback, &resource_fs_handle, &wicedfs_sflash_handle );
wiced_assert( "wicedfs init fail", result == 0 );
fs_init_done = ( result == 0 ) ? 1 : 0;
return (result == 0)? PLATFORM_SUCCESS : PLATFORM_ERROR;
}
return PLATFORM_SUCCESS;
}

PeterF's picture
PeterF
Moderator(16)

Correction to my earlier comment, that debugger message is seen here too (I'd misread your earlier posting and was looking for the warning elsewhere)
 

Per the earlier comment from Broadcom, you can disregard this warning and simply continue with stepping the debugger through the rest of the application code

Ok, according to the other thread this is a known issue?

https://community.broadcom.com/message/24997

 

PeterF's picture
PeterF
Moderator(16)

Correct, - Broadcom have confirmed that this a known issue.
You can safely ignore this and continue with your debugging session