SigmaStudio gave 'reserved' value for Register bit field...

Correcting myself about differing reset values: I was reading the tabled value for 'reset' not connecting that it was talking about the reset value for the bit field in question.

Problem (to me, at least) remains that not only the register I indicated but a few more (as I read more carefully, trying to verify SigmaStudio generated values) are apparently reset to values which are listed as 'reserved' in their tables.

This is a first for me, I have not noticed another device I have been asked to program for using reserved values for power-on/reset. Please advise.

EDIT: ASRCO_SOURCE_2_3 starts on reserved values and my target value is 0x36 which leaves [7:4] on the reserved value it resets to but changes [3:0] to a value which indicates the source I selected (ADC_2) for this; definite impression some of these 'reserved' values should have been called 'disabled' or 'none' OR ???

Hello Robert,

This is a bit unusual I agree and you are very clever to have noticed this. This part was originally made for a large customer with customer specific features. Even without these extra features it is still a cool part and has lots of applications so we decided to release it with the extra features bonded out during manufacturing. However, the default register settings during power up are hard-coded into the digital section of this part. So therefore, some of the default settings at power up are not valid settings for this part and it will not work with those settings.

So this will make it necessary to program a lot of registers from their default to get sound out of the part. When we made the SigmaStudio DLL I had the programmer set the DLL to default values that do make sense. So if you drop the chip into a new SigmaStudio schematic then hit "Compile/Link/Download" it will download those settings. Instead, if you "read settings from chip" you will see a lot of the SigmaStudio windows come up with reserved values or they may say "disabled" and you will have to make a lot of changes to get sound out of the part. You will not hurt anything if you set it to these values, it just will not work.

So if you are using a microcontroller to program the part then look at the default setting value. If it is not a valid setting then you will have to include that register in the configuration register writes in your software.

Dave T

Thanks very much Dave, jump to last paragraph for 'proper question' in this reply; I am just verbose really, although I do it in the hope maybe I can be (even) better advised.

I have been given "EVAL-ADAU1372 141006 Rev A" and "EVAL-ADUSB2Z 121005_1" but I am to pair the ADAU1372 with an alternative processor so I have not connected the USBi device yet - I went straight for connecting my chosen processor to the eval board using machined socket pins from header to header on short wires; for now just connecting to J1 SCL, SDA, 5V, BRD_RESET & GND from my experimental processor board which may as well be described as a "postage stamp".

So far I2C seems to be ignored - I write to device at 0x3C; 0x0,0x3 and when I read device at 0x3C; 0x0 I get 0x0 returned. The I2C library I am using returns errors to indicate if there was no acknowledgement from a slave at given address and this has me a little stumped but I am sure it is my own mistake somewhere here. I will review http://www.analog.com/media/en/technical-documentation/user-guides/EVAL-ADAU1372Z_UG-807.pdf & http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf some more but feel free to advise about this.

In the output file "test_IC_1_REG.h" the list of registers and values given has "ADC OPER; 0x60,0xA0" but I cannot find this register mentioned anywhere in the datasheet and if it is possible for me to know more about this register I would be very grateful, please advise. Once I have my I2C issue sorted, if the values I have chosen do not work out for my purpose I will probably post them later in this thread.

Hello Robert,

The address for I2C of 0x3C is the seven bits for the address. Then they are shifted over to make room for the read/write bit so actually, it is 0x78 for a write and 0x79 for a read. I know... confusing but try setting the address to 0x78 and it will probably work. Your software should automatically insert the read bit to make it 0x79 when needed.

Regarding register 0x60. SigmaStudio has a habit of writing to registers it should not be writing to. I will point this out to the software team. This register should not be written to at all. It can only cause problems.

Thanks,

Dave T

Thanks Dave but I've played I2C several times before and am familiar enough with those details, and the library I am using, for that not to be the problem I was experiencing - the last couple devices I have played with all used an 8-bit field for the register address and I was reasonably annoyed at myself that I had skimmed the relevant page in the datasheet and not noticed that I needed to write 16 bits for address regardless that there aren't that many registers in it.

I've had the eval board playing nicely with my mcu since (my) yesterday afternoon (is morning here now ) and I have kept that ADC_OPER register in my init sequence - I will drop it and I don't expect detriment but I will drop you a line if it seems to cause any.

Marvellous device, can't wait for prototypes of the next version of our main product - I think this will provide the best improvements yet. I do not love the datasheet but I've muddled my way through heaps worse. SigmaStudio 'export system' files seem clunky and perhaps even as much as bloated to me but I have had worse there too. Here, I will post a couple of snippets indicating why I think that about the files exported from SigmaStudio;

// adau1372 register defines

#define CLK_CONTROL 0x0

#define PLL_CTRL0 0x1

#define PLL_CTRL1 0x2

#define PLL_CTRL2 0x3

#define PLL_CTRL3 0x4

#define PLL_CTRL4 0x5

#define PLL_CTRL5 0x6

#define CLKOUT_SEL 0x7

...

void ControlADAU1372::init(void)

{

writeReg(CLK_CONTROL,0x3);

delay(400);

// writeReg(PLL_CTRL0,0x0); // not using PLL

writeReg(PLL_CTRL1,0x1);

// writeReg(PLL_CTRL2,0x0);

// writeReg(PLL_CTRL3,0x0);

writeReg(PLL_CTRL4,0x20);

// writeReg(PLL_CTRL5,0x1); // read only flag for PLL lock - not using PLL -wtf sigma studio?

writeReg(CLKOUT_SEL,0x7); // no clkout required

// writeReg(REGULATOR,0x0);

writeReg(DAC_SOURCE_0_1,0xDC);

// writeReg(SOUT_SOURCE_0_1,0x54); // reset value

// writeReg(SOUT_SOURCE_2_3,0x76); // reset value

...

I wrote a reasonably hacky little program to pull apart the first section of 'test-IC-1-REGS.h' to make the two lists for me - saved me a whole bunch of typing but considering the format of the source, and that this was the neatest representation of the required data...

/* CLK_CONTROL - Registers (IC 1) */

#define REG_CLK_CONTROL_IC_1_ADDR 0x0

#define REG_CLK_CONTROL_IC_1_BYTE 1

#define REG_CLK_CONTROL_IC_1_VALUE 0x3

/* PLL_CTRL0 - Registers (IC 1) */

#define REG_PLL_CTRL0_IC_1_ADDR 0x1

#define REG_PLL_CTRL0_IC_1_BYTE 1

#define REG_PLL_CTRL0_IC_1_VALUE 0x0

/* PLL_CTRL1 - Registers (IC 1) */

#define REG_PLL_CTRL1_IC_1_ADDR 0x2

#define REG_PLL_CTRL1_IC_1_BYTE 1

#define REG_PLL_CTRL1_IC_1_VALUE 0x1

...

Hello Robert,

If you don't mind my asking, what kind of product is this going into? Are you using both the ADCs and the DACs?

Thanks,

Dave T

forgive my tardy response Dave

Three inputs conditioned and mixed to one output is basic task. We were doing it with a TLV320AIC3204 and using an ADC channel on an MK20DX256VLH7 for the third input, we made that work well enough but the next version should put that to shame because the ADAU1372 is pretty awesome and not just because it has the extra two inputs.