EVAL-ADAU1452MINIZ load from microcontroller


I'm having trouble loading the DSP on  a EVAL-ADAU1452MINIZ board using our microcontroller.   The code is stable and ported from our ADAU1701 target hardware, with the changes required for the ADAU1452. 

I'm not confident that I've actually put the ADAU1452 in SPI mode (three times toggling the SPI SS low).   I check this by reading back the first few bytes of program memory and compare to the downloaded program.   However MISO reads back all zeros.   I enter hibernate mode and kill the core before reading program memory, as described here.  I have also introduced a delay following the reset of the DSP that accommodates the max reset pulse of the ADM811 reset generator used on the eval board.   I consistently read back all zeros from the DSP program memory, which is not what was downloaded.

Is there a simple way to verify that I've successfully entered SPI control mode?    Also, the microcontroller is using SPI mode 0, as recommended on this forum, even though the data sheet specifies mode 3--is that correct?  

  • Hi,

    The ADAU1452 support officially SPI mode 3 on the SPI slave port that you use with your MCU.

    The USBi sold with the evaluation board uses SPI mode 0, so the ADAU1452 unofficially support it.

    The ADAU1452 supports SPI mode 3 and 0 on the SPI master ports.

    Check that the SELFBOOT switch is off.

    The best way to test if the SPI is working is to upload a very simple sigmastudio project: a sinus source of 1kHz connected to one of the headphone output. This way it will be quite obvious to the user if the SPI transfer worked (1kHz sound) or not (no sound).

    Load it with USBi first, so you are sure that your eval board is working.

    Then use the export function, and load the project with your MCU. If you use SPI mode 0, the waveforms should be exactly the same (with a different timescale).

    What is important for the SPI:

    Use SPI mode 3 (or 0).

    Use a SPI clock frequency <3.072MHz at least until the PLL is locked. After, it could be raised up to 22MHz.

    MSB first.

    3x toggle SS low (or 3x dummies SPI write).

    You have to respect the SPI transfer format, in the case of the ADAU1452 it is:

    device adress (7bits) + readwrite command (1bit) + sub address (2bytes) + data (n bytes).

    You must put SS low before each SPI transfer, do the transfer, then back high.

    Best regards,

    Simon

  • Simon,  thanks for your reply.   Your suggestion to monitor SPI timing using the USBi is what revealed my programming error: I missed the detail that register addresses for the ADAU1452 are 16 bits, while they are 12 bits for the ADAU1701 from which my microcontroller code was derived.   After making that change, I can successfully load my ADAU1452 code and see my sine wave output.   I used SPI mode 0 for the writes to download the code.

    However, in the process, I made another observation.   In my microcontroller code, I verify correct download of the program by reading the first few bytes of program memory in the DSP and comparing it to the byte array in my microcontroller code.  The program memory read returned all ones if SPI mode 0 was used, so my test failed.  It and only returned the correct program memory contents if SPI mode 3 was used.  I was clocking SPI at 1MHz in either mode.  So my conclusion is that mode 3 is to be used for writes and reads.  Can anyone else verify this?

    In any case, my ADAU1452 program load and verification is now working. 

  • Hi,

    Program memory can only be written or read when the core is stopped.

    In fact, it is also true for DM0 and DM1 memories.

    Registers can be accessed at will.

    My verification algorithm checks:

    PLL_CTRL1

    PLL_CLK_SRC

    MCLK_OUT

    PLL_ENABLE

    Program memory, first 4*4bytes.

    DM0 memory, first 4*4 non-zero bytes.

    DM1 memory, first 4*4bytes.

    My application is reading successfully the same values in both SPI modes.

    Unlike the USBi, I'm using the following read waveform. First trace is SCK, second is SS. MCU side.

    The USBi use a huge ~700us gap between the command (first 3bytes) and data (last2bytes).

    SPI mode 0:

    Sample on rising edge. Data change on falling edge.

    Default 0. Start with a rising edge.

    SPI mode 3:

    Sample on rising edge. Data change on falling edge.

    Default 1. Start with a falling edge.

    Those two SPI mode are relatively identical!

    I use F=2MHz.

    My MCU works with 5V so I put resistors dividers (270R and 560R) on SCK, MOSI, SS. The GND and MISO are direct traces.

    (It cost less to have a 5V MCU and a 5V screen, and some resistors, than to have a 3.3V MCU, 3.3V screen and no resistors)

    I modified the ADAU1452 SPI registers to remove the default 3.3V pull-up on MOSI and SS, to set fastest slew-rate and strongest strength.

    Due to the fact that the ADAU1452 has surely CMOS input (2pF), the resistor dividers alter the signals slew-rate in a RC way. So I had to put a 6mA current into the resistor divider to have an acceptable slew-rate at 2MHz. (Less current means worse slew-rate)

    Here are my SCK waveforms scoped with two 10x probes and a very short GND connexion. The first trace is before the resistor-divider (MCU side), the second is after (DSP side):

    If you read false data on MISO, it could be that the signals are not well synced. In my example: a bad slew-rate on 3 of the 4 signals means a phase difference great enough to have a "corrupted" MISO answer from DSP.

    Best regards,

    Simon