CRC on 1446

drugoimir Question

Apr 18, 2014 00:00

Hello,

i've read that were some issues with the CRC generator on ADAU1442/6,

https://ez.analog.com/message/10660#10660

I've read also the solution proposed by Brett, which consists in clearing the

remaining program ram area and some other tricks to do on the compiled

hex file generated (i' did read it, but not in deep).

Since that discussion was 4 years old and thinking that ADI fixed this into the

last SigmaStudio, i tried "the easy way" using directly the file generated

by sigmastudio, but i see that some weird things are still present:

This is a program compiled without CRC check

void default_download_IC_1() {

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_START_PULSE_SELECT_IC_1_ADDR, REG_START_PULSE_SELECT_IC_1_BYTE, R0_START_PULSE_SELECT_IC_1_Default );

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_CORE_RUN_BIT_IC_1_ADDR, REG_CORE_RUN_BIT_IC_1_BYTE, R1_CORE_RUN_BIT_IC_1_Default );

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, PROGRAM_ADDR_IC_1, PROGRAM_SIZE_IC_1, Program_Data_IC_1 );

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_SERIALINPUT0_DEFAULT_IC_1_ADDR , R3_SERIAL_INPUT_MODES_IC_1_SIZE, R3_SERIAL_INPUT_MODES_IC_1_Default );

.....

This is what i get when i turn on the CRC error check

void default_download_IC_1() {

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_START_PULSE_SELECT_IC_1_ADDR, REG_START_PULSE_SELECT_IC_1_BYTE, R0_START_PULSE_SELECT_IC_1_Default );

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_CORE_RUN_BIT_IC_1_ADDR, REG_CORE_RUN_BIT_IC_1_BYTE, R1_CORE_RUN_BIT_IC_1_Default );

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, PROGRAM_ADDR_IC_1, PROGRAM_SIZE_IC_1, Program_Data_IC_1 );

SIGMA_WRITE_REGISTER_BLOCK( DEVICE_ADDR_IC_1, REG_SERIALINPUT0_DEFAULT_IC_1_ADDR , R10_SERIAL_INPUT_MODES_IC_1_SIZE, R10_SERIAL_INPUT_MODES_IC_1_Default );

.....

In this latter case, it seems that the program memory is being loaded 8 times (?) and also many registers are not defined.

Here are some, but there are many more:

R3_SERIAL_INPUT_MODES_IC_1_SIZE

R3_SERIAL_INPUT_MODES_IC_1_Default

R4_SERIAL_OUTPUT_MODES_IC_1_SIZE

So, what i've to do?

I've to "hack" the compiled hex as per Brett's workaround ?

May i apply the workaround on the "xxx.h, xx_param.h, xx_REG.h" files ?

I'm using those for device control and upload.

I'm about finishing this project and i'm missing just this feature, i cannot terminate it without.

Thanks for any advice.

Tom

adau144x

crc

Report

drugoimir Reply

Apr 28, 2014 00:00

No suggestions?

It seems a bug on sigmastudio...i cannot do anything.

Could ADI, please, give any suggestions?

Can the workaround be used on the *.H files or it

is to be applied only on hex files?

Regards

Report

Wilfrido Reply

Apr 29, 2014 00:00

Hello Tom,

Thank you for your feedback.

It is indeed a bug. The reason you're seeing multiple program writes (8) is because the compiler is making sure that the program is cleared (i.e. forcing to write zeros to the entire program memory). Therefore, we added up 7 pages (Block 0 - Block 6) of zeros. It seems that these blocks aren't mapped on the "Export files" as they should.

I will need to fix this issue. For now the only work around I could suggest is the following:

On the Data Capture window, you will notice that those blocks are being written. You can copy-paste the block information from each one (7). The good news, is that these are always zero. On your *.h file, manually implement this as:

#define BLOCK0_SIZE_IC_1 4092

#define BLOCK0_ADDR_IC_1 8192

ADI_REG_TYPE Block0_Data_IC_1[BLOCK0_SIZE_IC_1] = {

0x00,
0x00,
0x00,
0x00,
0x00,
0x00,

.....

}

#define BLOCK1_SIZE_IC_1 4092

#define BLOCK1_ADDR_IC_1 8874

ADI_REG_TYPE Block1_Data_IC_1[BLOCK1_SIZE_IC_1] = {

0x00,
0x00,
0x00,
0x00,
0x00,
0x00,

.....

}

....

And so on. I know this is hacky, but it will get you going.

Don't forget to add those block writes at the bottom of the file on the

default_download_IC_1() { } method.

I will fix this bug, so that you don't have to manually do it, but it won't be ready any time soon.

This will be on SigmaStudio 3.11.1 Beta release.

Many thanks,

Wilfrido.

Report

drugoimir Reply

Apr 30, 2014 00:00

Thanks Wilfrido,

i noticed also that many DSP registers got undefined, as reported by the host mcu compiler,

when i turn on the CRC check so i use the newly generated *.h files.

If you want, i can be more specific.

Regarding the zero filling, i understood you fill the program memory in 4092 zero-valued bytes chunks,

moving the address of the next block by 682 bytes, that is the initial address shifted by 4092 / 6 instructions

(because each instruction is 6 bytes long), until the whole program area is filled up with zeros.

So i'm asking, instead of zeroing the program memory then downoading the program,

may i download the whole program, then fill up the remaining memory with zeros?

I could do this without having to declare zero filled arrays, just simply making a loop and sending

a sequence of zeros into the spi-communication routine till program memory end.

Many thanks.

Tom

EDITED ON May 8th

Here are the registers that get undefined when i turn on CRC check.

Please give a word on this and if i can zero-fill the remaining program ram

programmatically, instead of defining a zero-filled array.

(re-edit) I see that the registers are not undefined, rather the Rx_REGISTER_NAME

identifier number (R4, R3 ..) become different if i compile with or without CRC

check.

This maybe because they are enumerated serially and with crc check there

are 8+ programming steps so only the first ones (those before program ram data)

are equal.

Many thanks.

Error 139 'R3_SERIAL_INPUT_MODES_IC_1_SIZE' undeclared (first use in this function)

Error 141 'R3_SERIAL_INPUT_MODES_IC_1_Default' undeclared (first use in this function)

Error 142 'R4_SERIAL_OUTPUT_MODES_IC_1_SIZE' undeclared (first use in this function)

Error 143 'R4_SERIAL_OUTPUT_MODES_IC_1_Default' undeclared (first use in this function)

Error 144 'R5_HIGH_SPEED_SLAVE_INTERFACE_MODE_IC_1_Default' undeclared (first use in this function)

Error 145 'R6_ROUTING_MATRIX_ASRC_INPUT_DATA_SELECTOR_IC_1_SIZE' undeclared (first use in this function)

Error 146 'R6_ROUTING_MATRIX_ASRC_INPUT_DATA_SELECTOR_IC_1_Default' undeclared (first use in this function)

Error 147 'R7_ROUTING_MATRIX_ASRC_OUTPUT_RATE_SELECTOR_IC_1_SIZE' undeclared (first use in this function)

Error 148 'R7_ROUTING_MATRIX_ASRC_OUTPUT_RATE_SELECTOR_IC_1_Default' undeclared (first use in this function)

Error 149 'R8_ROUTING_MATRIX_SERIAL_OUTPUT_DATA_SELECTOR_IC_1_SIZE' undeclared (first use in this function)

Error 150 'R8_ROUTING_MATRIX_SERIAL_OUTPUT_DATA_SELECTOR_IC_1_Default' undeclared (first use in this function)

Error 151 'R9_SPDIF_REGS_IC_1_SIZE' undeclared (first use in this function)

Error 152 'R9_SPDIF_REGS_IC_1_Default' undeclared (first use in this function)

Error 153 'R10_ASRC1_MUTE_IN_OUT_IC_1_Default' undeclared (first use in this function)

Error 154 'R11_ASRC2_MUTE_IN_OUT_IC_1_Default' undeclared (first use in this function)

Error 155 'R12_SERIAL_IN_FLEX_MODES_IC_1_SIZE' undeclared (first use in this function)

Error 156 'R12_SERIAL_IN_FLEX_MODES_IC_1_Default' undeclared (first use in this function)

Error 157 'R13_SERIAL_OUT_FLEX_MODES_IC_1_SIZE' undeclared (first use in this function)

Error 158 'R13_SERIAL_OUT_FLEX_MODES_IC_1_Default' undeclared (first use in this function)

Error 159 'R14_DSP_REGS_IC_1_SIZE' undeclared (first use in this function)

Error 160 'R14_DSP_REGS_IC_1_Default' undeclared (first use in this function)

Error 161 'R15_OTHER_DSP_MODES_1_IC_1_SIZE' undeclared (first use in this function)

Error 162 'R15_OTHER_DSP_MODES_1_IC_1_Default' undeclared (first use in this function)

Error 163 'R16_OTHER_DSP_MODES_2_IC_1_SIZE' undeclared (first use in this function)

Error 164 'R16_OTHER_DSP_MODES_2_IC_1_Default' undeclared (first use in this function)

Error 165 'R17_MASTER_CLK_ENABLE_IC_1_Default' undeclared (first use in this function)

Error 166 'R19_IC_1_IC_1_ADDR' undeclared (first use in this function)

Error 167 'R19_IC_1_IC_1_SIZE' undeclared (first use in this function)

Error 168 'R19_IC_1_IC_1_Default' undeclared (first use in this function)

Error 169 'R21_START_PULSE_SELECT_IC_1_Default' undeclared (first use in this function)

Error 170 'R22_CORE_RUN_BIT_IC_1_Default' undeclared (first use in this function)

Error 171 'R23_DEJITTER_WINDOW_IC_1_Default' undeclared (first use in this function)

Error 172 'R24_DEJITTER_WINDOW_IC_1_Default' undeclared (first use in this function)

Report

drugoimir Reply

May 9, 2014 00:00

Hello Wilfrido,

i did what you said, and i got it working, thanks.

To save controller memory i implemented a routine to send

24576 zeros to clear DSP program memory.

Don't take into account what i wrote about things becoming undefined, it

is because you name them differently when you do a normal export or

a "CRC" export.

I'm now facing another problem: i have two DSPs, i correctly download

the firmware on both and they start correctly without errors.

If, after a while, i read some values (audio levels) from a DSP,

i get a CRC error on a gpio used ar CRC error sticky.

I can clear it simply disabling CRC detection and re-enabling it; i don't have

to resend all the firmware: even if there is a CRC error indication, both DSP are

working correctly.

I was pretty sure i'd found the same issue in the forum:

https://ez.analog.com/message/114369#114369

but there was no answer.

So, why does the IIC activity trigger false CRC errors?

Any ideas on what could it be?

Report