Hi Team,
We are currently evaluating your DA7219 audio CODEC using your 284-02-D board. But we have having some issues that we need help with. I am unsure where the problem is originating from, and so hoping you might have some comments on known issues and or limitations with the system.
Firstly - Our current setup is a relatively clean install of Windows 10 Pro (Version 1709) running on a Dell Laptop with an i7-8650 and 16GB of RAM (so a fairly capable machine).
I have version 1.1.0.12 of the DA7219 smartcanvas installed, along with version 1.2.6.0 of the libusb-win32 driver (provided with the smartcavas software). I believe this is the most up-to-date copy of the software available through your support forum (and was also provided on the USB that came with the performance board).
The local audio configuration has been setup to route to the USB device, as per the Readme and quick start document.
The smartcanvas software can connect to the board without issues, but once the "Slave_PLL_SRM_12MHz_48k_16bit_I2S_USB_AUDIO.txt" script was executed, we noticed console errors indicating the SDA line was pulled low:
2019-02-27, 21:07:02 [ERROR] Read Failure (bus=i2c, slave=0x96, address=0x0000) 2019-02-27, 21:07:02 [ERROR] read 0000 failed with exception: ('USB-Lab_IO ERROR: 15 SDA line is LOW (extra info: I2C slave 0x97)', 15) 2019-02-27, 21:07:02 [ERROR] Read Failure (bus=i2c, slave=0x96, address=0x0000) 2019-02-27, 21:07:02 [ERROR] read 0000 failed with exception: ('USB-Lab_IO ERROR: 12 Arbitration lost (extra info: I2C slave 0x97)', 12)
In this setup the polling configuration was for reading the entire register set, with an I2C speed of 400kHz, with a period of 100ms. Reducing the speed usually fixes this issue. This leads to my first question - is this a typical limitation for the 284-02-D board, or might it be indicative of manufacturing flaws? Sometimes there are also intermittent issues where the I2C consistently fails with the following warning after trying to execute a load script to initially configure the PLL:
2019-02-27, 21:37:17 [ERROR] Write Failure (bus=i2c, slave=0x34, address=0x0013, data=0x80) 2019-02-27, 21:37:18 [ERROR] read 0025 failed with exception: [Errno 9] Bad file descriptor 2019-02-27, 21:37:18 [ERROR] Read Failure (bus=i2c, slave=0x34, address=0x0025) 2019-02-27, 21:37:18 [WARNING] PLL calculator addon failed to read PLL status bits 2019-02-27, 21:37:19 [ERROR] gpio get state failure [port: B, linenum: 8] 2019-02-27, 21:37:19 [CRITICAL] [Errno 9] Bad file descriptor
Working with the lower I2C clock and the MCLK sourced from the 12.288MHz oscillator, we an manipulate registers and monitor Accessory Detection Events. What we could not do however, is generate audio out the Headset socket, be that via USB originated audio, or via the built-in Tonegen. I have tried a number of PLL configurations, but with no success.
Regardless of the MCLK and PLL setting, when performing playback or recording via USB audio, the bit clock is indeed driven at 1.536MHz (consistent with 16bit 48kHz stereo audio), however the word clock and DOUT are not clocking. My instincts are that the issues are related the the SAM3U processor on the board, that it is incorrectly performing I2C operations, MCLK generation, and/or I2S signal generation. Do you have any comments here? Or would do you have a newer version of the firmware for this chip that I could flash to the processor?
When a headphone is plugged in, we can also head a significant amount of noise, while the charge pump is active and the headphone output is enabled. Is this also typical for the 284-02-D performance board?
If you are able to provide some guidance on these issues, it would be greatly appreciated.
Thank you for your continued support.
Kind Regards, Cameron