Page 1 of 1

Initialize config custom values

Posted: Thu Feb 09, 2017 1:43 pm
by OscarMa
After tuning and flashing the xCORE VOICE Smart Microphone board, I would like to change
the default value of the parameters. Therefor the function il_voice_get_default_cfg_xmos() is used to change the parameters.
which is located in "app_usb_aud_mic_array/src/extensions/xvsm/xvsm_dsp.xc

The problem is that after rebooting the configuration is overwritten
with the initial values but not with the custom values on the il_voice_get_default_cfg_xmos() function.


Is there some other init that is writing this non-default values after this function? Should I build my one init (batch file)?


/* TODO this needs to be called on reset */
void il_voice_get_default_cfg_xmos(il_voice_cfg_t &ilv_cfg, il_voice_rtcfg_t &ilv_rtcfg)
{
/* Initialize config structures to viable default values */
il_voice_get_default_cfg(ilv_cfg, ilv_rtcfg);

/* Setup parameters in config structure */


ilv_rtcfg.bypass_on = 0;
ilv_rtcfg.mic_shift = 4;
/*Beamformer*/
ilv_rtcfg.bf_on = 1;
ilv_rtcfg.bf_focus = 10;
ilv_rtcfg.bf_diffgain_dB = -10;
/*Noise suppression*/
ilv_rtcfg.ns_on = 1;
ilv_rtcfg.ns_attlimit_dB = -20;
/*de-reverb*/
ilv_rtcfg.rvb_on = 1;
ilv_rtcfg.rvb_attlimit_dB = -20;
/*Echo control*/
ilv_rtcfg.aec_on = 1;
ilv_rtcfg.aec_strength = 10;
ilv_rtcfg.aec_force_thr_dB = -10;
ilv_rtcfg.aec_noise_thr_dB = 15;
ilv_rtcfg.aec_dt_thr_dB = 20;
ilv_rtcfg.aec_dt_release_dB = 10;
ilv_rtcfg.aec_dt_att_limit_dB = -30;
ilv_rtcfg.aec_no_adapt = 0;
/*Auto gain control*/
ilv_rtcfg.agc_on = 1;
ilv_rtcfg.agc_init_gain_dB = 36;
ilv_rtcfg.agc_target_dB = -10 ;

/*For more info go to -> lib_xvsm_support/api/xvsm_support.h*/

}




Many thanks

Re: Initialize config custom values

Posted: Fri Feb 10, 2017 10:48 am
by johned
I would store the persistent values in FLASH : https://www.xmos.com/download/private/A ... rc1%29.pdf.
Then load them at boot time.

Best regards,
John

Re: Initialize config custom values

Posted: Fri Feb 10, 2017 1:00 pm
by infiniteimprobability
Is there some other init that is writing this non-default values after this function? Should I build my one init (batch file)?
There shouldn't be. As you can see from the source, the function:

Code: Select all

void il_voice_get_default_cfg_xmos(il_voice_cfg_t &ilv_cfg, il_voice_rtcfg_t &ilv_rtcfg)
is called from:

Code: Select all

void dsp_process(server dsp_if i_dsp, server interface control i_control, const size_t num_modules)
which itself is called from the top level in main.xc:

Code: Select all

    //XVSM DSP processing
    on tile[0]: dsp_process(i_dsp, i_control[0], NUM_MODULES);
So the params should be set after boot/reset before entering the while(1) processing loop. The processing il_voice_process() reads in this control struct each iteration so should take whatever control values have been set. It should not modify these itself. The only way these should change is on handling of a control event

Code: Select all

 case i_control.write_command(control_resid_t resId, control_cmd_t cmd, const uint8_t data[n], unsigned n) -> control_resid_t res:
Are you sure that you are loading the right image? Is there an old version of the app in flash with different values perhaps?

Re: Initialize config custom values

Posted: Fri Feb 10, 2017 5:27 pm
by OscarMa
I am using the xTIME Composer to flash the board.

First I am loading my custom image from this application: app_usb_aud_mic_array_1i2o2_xvsm2000.xe with Boot partition size (byte): 0x80000.
After flashing the board, appears this error:

Warning: F03098 Factory image and boot loader cannot be write-protected on flash device on node 0

Site 0 has started.
Site 0 has type 005.
Site 0 write 0x00000000.
Site 0 verified 0x00000000.
Site 0 write 0x00000400.
Site 0 verified 0x00000400.
Site 0 write 0x00000800.
Site 0 verified 0x00000800.
Site 0 write 0x00000c00.
....
Site 0 has finished successfully.


So the default image is one more time flash.


As Johned said, the best option seems to be, to store persistent data in the FLASH and then load it at boot time.

Re: Initialize config custom values

Posted: Fri Feb 10, 2017 6:18 pm
by infiniteimprobability
Warning: F03098 Factory image and boot loader cannot be write-protected on flash device on node 0
That's not an error - just a warning to say that the flash used on the board doesn't have a bootblock protection feature. So it seems the flashing was completely successful (it is fully verified).

As Johned said, the best option seems to be, to store persistent data in the FLASH and then load it at boot time.
Yes you could do that, or just have code that initialises your parameters to constant values, like you are already doing. All code is stored in flash (when you do xflash), and is copied across to RAM at flash boot time, and is then executed with all of the constants included. So effectively, you are already storing your parameters in flash in the boot image..

Re: Initialize config custom values

Posted: Mon Feb 13, 2017 6:36 pm
by OscarMa
The init values seems to be set from this header: xvsm_control.h
After flashing and reboot, the parameters are set with the values from xvsm_control.h, and
the parameters from the il_voice_get_default_cfg(ilv_cfg, ilv_rtcfg); function are ignored or overwritten.

When exactly are this INI values from xvsm_control.h flashed on this device?
Should I flash this parameters one more time on the boot partition or create a data.bin file?


Many thanks for your support

Re: Initialize config custom values

Posted: Tue Feb 14, 2017 11:50 am
by OscarMa
The issue is solved. I removed all other images and made a clean project and build a new .xe c++ application.
After reset and reboot the values of the parameters from il_voice_get_default_cfg(ilv_cfg, ilv_rtcfg); remain, the problem was a conflict with the old images
flashed on the device.


One more time, thanks for your support.

Re: Initialize config custom values

Posted: Tue Feb 14, 2017 11:54 am
by infiniteimprobability
The issue is solved.
Oh that's good! I was struggling to see where else the values could be written so it's good to get confirmation that the issue came from elsewhere.

Thanks for sharing.