Post Go back to editing

SigmaStudio+ hardware configuration versus CCES Target firmware

Category: Hardware
Product Number: ADSP-21565

Hello,

Could you explain how SS+ interacts with hardware ressources like SPORTs, PCG, DAI... and how this interacts with the Target firmware?

I use a custom ADSP-21565 board and I already configured a working I2S passthough without SS+. More info here: I2S passthrough on custom board

I use SigmaStudio+ 2.4.0 and CCES 3.0.3.

I am now integrating a SS+ schematics in the CCES project using 'Export System Files' and ExportCodeParam.exe. I already did it successfully several time on the evaluation board with ADSP-21569. The main difference being that the custom board does not have L3 memory, so I placed ss_app_uc_data in L2. Either like this:

dxe_l2_uncached_bw BW
{
INPUT_SECTION_ALIGN(4)
INPUT_SECTIONS( $OBJS_LIBS(seg_l2_uncached seg_uncached ss_app_uc_data) )
} > MY_L2_UNCACHED_MEM

Or like this:

dxe_l2_data_bw BW
{
// L2 data.
INPUT_SECTION_ALIGN(4)
INPUT_SECTIONS( $OBJS_LIBS(seg_l2 seg_l2_dmda_bw seg_dmda_bw seg_dmda ss_app_uc_data seg_vtbl .rtti .cht .edt) )
} > MY_L2_CACHED_MEM

It does not seem to change anything.

I have a very loud digital noise on the audio output of the DAC, which changes in frequencies when I plug or unplug the input of the ADC. So there seem to be a direct correlation between input and output.

What is also interresting is that if I comment 'adi_ss_schematic_process' line, the passthrough works. So if I am not mistaking, CopyFix2Float and CopyFloat2Fix behave as expected (and if I also comment 'CopyFloat2Fix ' I have silence on the output which confirm this).

memcpy(nTempBuff, pSportIn, BLOCK_SIZE * NUM_CHANNELS_IO * sizeof(int));

/* Fixed to float conversion and copy to SS input buffer */
for(i=0; i<NUM_CHANNELS_IO; i++)
{
CopyFix2Float((volatile uint32_t*)&nTempBuff[i], NUM_CHANNELS_IO, pSSInBuff[i], 1, BLOCK_SIZE, 1u);
}

/* Call to the Schematic processing */
eSSRes = adi_ss_schematic_process(hSSnHandle, BLOCK_SIZE, (adi_ss_sample_t **)pSSInBuff, (adi_ss_sample_t **)pSSOutBuff, pSSnProperties);
if(eSSRes != ADI_SS_SUCCESS)
{
printf("\adi_ss_schematic_process failed");
exit(-1);
}

/* Float to fix conversion and copy back to SPORT buffer */
for(i=0; i<NUM_CHANNELS_IO; i++)
{
CopyFloat2Fix(pSSOutBuff[i], 1, (volatile uint32_t *)&pSportOut[i], NUM_CHANNELS_IO, BLOCK_SIZE, 0u);
}

Additionally to this, if I manage the passthrough differently without using nTempBuff or CopyFix2Float/CopyFloat2Fix, adding 'adi_ss_schematic_process' will break the passthrough, ADC callbacks stop and I have silence on the DAC output. Even if 'adi_ss_schematic_process' works on completely separate data than my ADC/DAC. My understanding is that 'adi_ss_schematic_process' messes with my SPORTs and clocks configuration.

Do I need to configure SPORTs in SS+ as well as in my firmware? Or can I just use 'adi_ss_schematic_process' as a simple audio processing function and manage hardware configuration by hand in my Target firmware?

I would like SS+ schematics to stay away from hardware ressources, and choose which buffers I feed it myself, in the Target firmware. Is this possible?

This is especially needed because I will manage different inputs and outputs in the firmware, and I would like to keep SS+ schematic simple, with one stereo input, and only feed it one type of input at a time. For example I2S ADC. Then maybe switch to SPDIF in the Target firmware without SS+ knowing about it.

Thank you for any help you could provide me.

Here are some settings of my SS+ project:

Fabien

Edit Notes

fixed link and typo
[edited by: Fabien33 at 9:26 AM (GMT -4) on 6 Oct 2025]

Thread Notes