Compile error ADAU1452 Master control port SPI

Hello ,

Can you send over the XML file you are using?

Dave T

Dave,

I'm attaching the XML file that I'm using, which I obtained from ADI web site (wiki, I think). My goal is to confirm whether the ADAU1452 can configure the SPI-based peripherals in our product on startup, and then and then update their settings periodically. One of the peripherals is a DDS (AD9850) which I know does not conform to the SPI command protocol (i.e., R/W bit, global address, sub-address, etc.) but I'd be happy at this point to simply be able to send out some bytes using SPI mode of the Master Control Port.

I have the eeprom removed from the EVAL-ADAU1452 that I'm using,and I have jumpered the master SPI signals to the peripheral for testing. Now I'm just trying to implement a simple schematic that can do the start-up configuration and the periodic updates, which is the point where I ran into the compile error. The examples in the Wiki show I2C examples, so the path to use master SPI is not so clear.

Thanks,

John

Hello John,

It loos like SPI Mode 0 is the issue. It works fine with SPI mode 3. The programming team says this will be fixed with the next release.

Dave T

Thanks for looking into that, Dave, it's helpful to know. Is there a date for planned release of next version?

I can see that the Master Control Port has features to support the programming of peripherals like ADI codecs that conform to SPI command format (i.e., R/W bit, global address, register-address, etc.) .

Could you comment on whether it's possible to to send SPI data that doesn't conform to that protocol, for example, by setting "sub-address bytes" and "command length" equal to 0? I'm going to try that out since it's not clear from documentation, but I wondered if you had some insight you could share?

Hello John,

I am usually the last person to be told when the next release is coming out. I did hear that end of December is the next target date. There may be a beta version out soon. In fact,... I see that it is now available for download! See, I am the last to know.

Regarding Master SPI port flexibility. I have not experimented too much with what you described. I do know that booting up is only SPI mode 3 and that it is only 8bit based. So for instance you cannot write 10 bits. Otherwise, I think setting the sub-address and command bytes to zero might do what you desire. Let us all know. If you run into issues let me know and I will inquire back to the designers.

Dave T

Dave,

Thanks for the reply about the sub-address and command bytes, that's helpful.

However, I just tried the Beta release 3.16.1, and the compile error remains with the project and XML file using SPI, that I provided previously:

###### IC 1 ###### ADAU145X Assembler, Analog Devices Inc. Version: 3.16.1,1740 (built 11/3/2017)

##### Compile Started: Saturday, December 02, 2017 9:06:29 AM #####

error (44,ControlPort12): The name 'i2c_speed0' in memory 'DM0' is undefined in module __MASTER_CONTROL_PORT0__ (732)

error (45,ControlPort12): The name 'i2c_address_bytes0' in memory 'DM0' is undefined in module __MASTER_CONTROL_PORT0__ (733)

##### Compile FAILED: 2 errors, 0 warnings #####

Hello John,

The current 3.16.1 release is still the beta release. It does not have all the updated bug fixes in it. Let's wait for the new full released version before I report back to the software team.

Just this morning I received some notifications for things that will be included in the 3.16 release so I know that the beta version is not complete.

Dave T

Hello John,

I thought I would report back some of my findings since this may help you devise a work-around. I acquired a scope that decodes SPI transactions so I could easily capture what was actually being sent. I used your "AD1938" file as a test file. I found quite a few bugs and learned about how this was implemented. I have prepared a report to our programming team to get this fixed at some point. I only tested the Startup Boot cell to boot up an external device at startup. Here is what I found:

It treats all devices as if they are a memory device. So the first thing it does it it will send out a "Read" instruction from address 00 of one byte so you will see that full transaction with the SS line going low then high. When I describe a transaction I will mean a full toggle of the SS line.

The next transaction is actually garbled to where it will be ignored by the codec. So it performs a Write-Enable as if it were a memory device. Then it omits the actual Write instruction then transmits the address and data of the first entry in the XML file.

Then it will send a single byte transaction of the contents of the Write-Enable field in the properties window.

Then it properly sends the second message in the XML file.

Then it sends another write enable.

Then it delays for around 93ms. This is the delay command in the XML file.

Then it sends out another write-enable

Then it sends out the final message in the XML file.

Other things to note:

The Chip Address in the XML file is ignored. So you have to enter the chip address along with the read/write instruction in the proper fields of the Properties window. So I entered an "8" for the Write Instructions and a "9" for the Read Instruction.

Then another thing I found is that the address for the register in the XML files needs to be in decimal not hex. The data is treated as text so it has to be a hex number.

Another irritating thing is that if you are changing to a new file and there is a syntax issue in the file you will not get an error message and it will simply continue to use the last valid data it loaded. So you think you loaded in a new file but it will keep sending out the old data. So that behavior needs to change.

So my workaround for the first message being garbled (the missing write instruction) is to simply duplicate the first message in the XML file and then it sends it out properly the second time.

I also experimented with the delay instruction. It looks like it delays around 1.5ms times the number in the delay field.

I tried the following:

Delay = 01, I got around 1ms of delay

Delay = 02, I got around 2ms of delay.

Delay = 32, I got around 50ms of delay

Delay = 64, I got around 100ms of delay. (It was closer to 93ms so these numbers are rough numbers)

I will see if I can find out the actual formula.

I hope this helps. This will not be fixed in the upcoming release 3.16. I will hope this will get done for the 3.17 release.

Thanks,

Dave T