SRC4392: Channel Status Bits are always all 0

Hello,

In most cases the 0 indicating no error but if you try to write in it  and  it is not updating the channel status, points to a register set up. I put the list of steps that you might want  to check. 

1)  Please refer to table 2. Register Page Selection:

Register Page 2 contains the digital interface transmitter (or DIT) channel status and user data buffers. These buffers correspond to the data contained in the C and U bits of the transmitted AES3-encoded data stream. The contents of these buffers may be written through the SPI or I 2C serial host interface to configure the C and U bits of the transmitted AES3 data stream. The buffers may also be read for verification by the host system. See Table 7 for the DIT channel status buffer map, and Table 8 for the DIT user data buffer map.

Register 7F: Page Selection Register - will  select one of three register pages for write and/or read access via the SPI or I 2C serial host interface.

PAGE1=1 & PAGE0=0    will set  up   Page 2 for DIT Channel Status and User Data Buffers. Table 7 and  8 in datasheet show the buffer maps for  DIT channel status and user data buffers.

2)Register 08: Transmitter Control Register 2

TXBTD Transmitter C and U Data Buffer Transfer Disable: This bit is used to enable and disable buffer transfers between the DIT User Access (UA) and DIT Transmitter Access (TA) buffers for both channel status (C) and user (U) data. Note: The TXCUS0 and TXCUS1 bits in control register 0x09 must be set to a non-zero value in order for DIT UA buffer updates to occur.

Also note, Channel status and user data is stored in block-sized buffers, which may be accessed via the SPI or I 2C serial host interface, or routed directly to the general-purpose output pins (GPO1 through GPO4).  Just as  confirmation read the channel status at GPO as well.

I will be out of office until Tuesday so  if this does not solve your problem, please  you can contact me on Tuesday again.

Regards,

Arash

Hello.    Yes, we are changing to page2.  Each time we receive the hardware interrupt, we read reg 0x0A to clear the TBTI interrupt flag, then we set the TXBTD bit in reg 0x08, then we change to page 2 with this command writeReg(0x7F, 0b00000010), we then write all the bytes, then change back to page 0, then write all 0 to reg 0x08 so that the UA buffer transfers can return to normal.  Yes, we have also set TXCUS bits in reg0x09 to 01 (which is update by spi).   BLS is set to output in reg0x07.    And, the desired 24bit audio data is appearing in the AES3 stream... but channel status remains at all 00's. 

Hi Dedrick,

Arash is currently out of office and will be for the remainder of the week, please be patient as his responses will be delayed.

Thanks,

hello.  any update?

Hello,

 it seems you are doing it correctly then , may be something in the script is causing this. Can i take a look at your script?   

which GUI  you are using with this part?

Regards,

Arash

I'm not sure what you mean by GUI....  we are running code on a microcontroller and addressing the SRC4392 via the SPI bus.   We have been successfully using the DIR, Tx-Bypass Mux, PortA, PortB, and the SRC functions in our prototype.  We have been reading the in/out sample rate converter ratios.... pretty much everything is working except for this!   We are even seeing the expected interrupts when using the DIT

The SPI bus is running at roughly 31MBps.

To configure our prototype for analog input, we the setup function performs these writes (all verified working):

reset(); // Pull nRST pin low for 2us

vTaskDelay(2 / portTICK_PERIOD_MS);

writeReg(0x01, 0b00111111); // Remove PDALLn; pwr on all

writeReg(0x03, 0b00111001); // Port-A: Output source=SRC; master; i2s format

writeReg(0x04, 0b00000000); // Port-A: MClk; [1:0] 00/128; 01/256; 10/384; 11/512

writeReg(0x05, 0b00000001); // Port-B: slave; i2s format

writeReg(0x07, 0b00001100); // Tx: DIT Clk=Mclk; div by 128; DIT source=PortB Input; BLSM output; data valid

writeReg(0x09, 0b00000001); // Tx: Validity bit comes from 0x07; Buffers SHALL BE UPDATED by the i2c/SPI host

writeReg(0x0B, 0b00000001); // Unmask buffer transfer complete interrupt

writeReg(0x0D, 0b00001011); // DIR settings:  RefClk=MClk; source=Rx4;

writeReg(0x0E, 0b00001000); // [2:1] 00 passthru; 01 /2; 10 /4; 11 /8; bit3 mute on loss of lock; RXCKO=disable

writeReg(0x0F, 0b00100010); // PLL crap for DIR; sets PLL1 time base to 48kHz

writeReg(0x10, 0b00000000); // PLL crap for DIR; sets PLL1 time base to 48kHz

writeReg(0x11, 0b00000000); // PLL crap for DIR; sets PLL1 time base to 48kHz

writeReg(0x2D, 0b00000010); // SRC: source=DIR; rest default

writeReg(0x2E, 0b00100000); // SRC: AutoDeEmph=On; rest default

Then, to service the interrupt, we do the following:

readReg(0x0A, &regVal, sizeof(regVal));

writeReg(0x08, 0b00001000);

writeReg(0x7F, 0b00000010);  // Page 2 select for loading Tx AES3/IEC60958 metadata into DIT block

writeReg(0x00, 0b10100000);

writeReg(0x01, 0b10100000);

writeReg(0x02, 0b01000000);

writeReg(0x03, 0b01000000);

writeReg(0x04, 0b00110100);

writeReg(0x05, 0b00110100);

writeReg(0x06, 0b00000000);

writeReg(0x07, 0b00000001);

writeReg(0x08, 0b00011000);

writeReg(0x09, 0b00011000);

writeReg(0x2C, 0b00000011);

writeReg(0x2D, 0b00000011);

writeReg(0x7F, 0b00000000);

writeReg(0x08, 0b00000000);

I can verify that clearing the interrupt is working as well as that final write to reg0x08 (because if I remove those lines, the interrupts stop coming) - but I cannot verify that the SRC4392 changed register pages, and the metadata is all 00's.

I don't see any issue with the script  and seems you are doing everything by book. At this point the only suggestion that I have is to see if you can put some delays between the write operations and read them back after the delay. Can you write and then  read it back  and then after some delay read back the same register  -just to see if it is changing after sometime. Something like:

w register x

r  register x 

Delay  10m

r register x 

w register y

r register y 

Delay  10m

r register y

yes - we can try this....

One additional question I have regarding the Channel Status registers - do they reset to 00's after they have been transferred over to the DIT?  Or, are the values sticky?     If they clear out every time, we'll have to be careful with the delays because at the highest sample rate coming in via port B, the Buffer Transfer Complete interrupt comes every millisecond.

I believe they are sticky registers. 

Dedrick , thanks for sharing the cause.