Writing to DCT during runtime

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

cross mob
Anonymous
Not applicable

Hi,

I've tried to use wiced_dct_read_lock/wiced_dct_read_unlock with ptr_is_writable = WICED_TRUE in order to write to the DCT.

It didn't work.

Reviewing waf.c, it doesn't looks like  wiced_dct_read_lock/wiced_dct_read_unlock expected to support DCT writing to external flash.

Am I missing something here ?

( i.e. what other functionality I'm supposed to use in order to update the DCT during runtime ? )

0 Likes
1 Solution
Anonymous
Not applicable

Hi,

The DCT locking and unlocking mechanism is used as an optimized way of getting pointers to DCT (if for reading you don't need to allocate memories). The way to access it is how it is done in dct_read_write example, you lock, update then unlock. there is an explicit call for wiced_dct_update (to avoid writing to flash if you didn't actually change any thing).

if you want to move the update to the unlock, (despite not its job), that's your call, however we believe a function should do what its name indicate (just unlock)

Regards,

Bassem

View solution in original post

0 Likes
6 Replies
Anonymous
Not applicable

ok.. so I was slightly mislead by the eclipse marking the EXTERNAL_DCT as defined for my platform..

yet, the issue remains. The unlock definition is this :

wiced_result_t wiced_dct_read_unlock( void* info_ptr, wiced_bool_t ptr_is_writable )

{

#ifdef EXTERNAL_DCT

    UNUSED_PARAMETER( ptr_is_writable );

    free( info_ptr );

#else

    if ( ptr_is_writable == WICED_TRUE )

    {

        free( info_ptr );

    }

#endif /* ifdef EXTERNAL_DCT */

    return WICED_SUCCESS;

}

which seems to lack any sort of "writing" before deleting the temporary RAM memory copy.

0 Likes

What exactly is your end goal?  I ask because there might be another way to achieve your goal without using the DCT updates.

0 Likes
Anonymous
Not applicable

My goal is to have the user changing the device configuration ( i.e. the way it's functioning ) from a web browser.

Since the DCT is the device's persistent storage, it's suppose to work. when applying the following changes to the WICED SDK 3.1.2, it work ( and I wish Broadcom would incorporate similar solution into the next SDK.. ) :

wiced_result_t wiced_dct_read_lock( void** info_ptr, wiced_bool_t ptr_is_writable, dct_section_t section, uint32_t offset, uint32_t size )

{

    if ( ptr_is_writable == WICED_TRUE )

    {

    // allocate extra 12 bytes.

        *info_ptr = (void*)malloc_named( "DCT", size + 12 );

        if ( *info_ptr == NULL )

        {

            return WICED_ERROR;

        }

        *((uint32_t*)*info_ptr) = section;

        *(((uint32_t*)*info_ptr)+1) = offset;

        *(((uint32_t*)*info_ptr)+2) = size;

        *info_ptr = ((char*)*info_ptr)+12;

        wiced_dct_read_with_copy( *info_ptr, section, offset, size );

    }

    else

    {

        *info_ptr = (char*)wiced_dct_get_current_address( section ) + offset;

    }

    return WICED_SUCCESS;

}

wiced_result_t wiced_dct_read_unlock( void* info_ptr, wiced_bool_t ptr_is_writable )

{

    if ( ptr_is_writable == WICED_TRUE )

    {

    dct_section_t section = *(((uint32_t*)info_ptr)-3);

    uint32_t offset = *(((uint32_t*)info_ptr)-2);

    uint32_t size = *(((uint32_t*)info_ptr)-1);

    wiced_dct_update(info_ptr, section, offset, size );

        free( ((char*)info_ptr)-12 );

    }

    return WICED_SUCCESS;

}

note that I've eliminated the EXTERNAL_DCT since it's irrelevant for my application.

0 Likes
Anonymous
Not applicable

Hi,

What is your platform?

Did you try the DCT read write snip app (Apps/snip/dct_read_write)? is it working or are you facing the same problem?

Regards,

Bassem

0 Likes
Anonymous
Not applicable

Hi,

I'm using the BCM943362WCD4 platform.

Please correct me if I'm wrong, but the goal of the wiced_dct_read_lock/wiced_dct_read_unlock function pair was to work as accessors.

When we pass WICED_TRUE, it's suppose to allow us to modify the data.. which is clearly not working.

( the code is quite trivial ).


The Apps/snip/dct_read_write sample, uses wiced_dct_write to perform the actual write. That would work with the "incorrect" implementation. But if the implementation is to be corrected, that would no longer be required.


0 Likes
Anonymous
Not applicable

Hi,

The DCT locking and unlocking mechanism is used as an optimized way of getting pointers to DCT (if for reading you don't need to allocate memories). The way to access it is how it is done in dct_read_write example, you lock, update then unlock. there is an explicit call for wiced_dct_update (to avoid writing to flash if you didn't actually change any thing).

if you want to move the update to the unlock, (despite not its job), that's your call, however we believe a function should do what its name indicate (just unlock)

Regards,

Bassem

0 Likes