Page 13 also says rev 5 and rev 7 don’t use I2C to configure codec. Shouldn’t that be rev 4 and rev 7?
Hi Andrew.
thanks for updating the datasheet, it helps a lot understanding.
Actually my Daisy Seed 1.2 has a different scheme, what I’ve found is this:
The scheme is not compliant with libDaisy as PB11 is not connected, but PH4 is.
It would be great if you may update the documentation but it would be even better
if you consider making a couple of very little changes to the board so that the connection to PB11 is restored, the connection to PH4 is kept and you add a jumper
between pin 27 and 28 of the codec, normally open, so that it’s possible to set
the codec to I2C mode.
The it’s still possible to make it on the existing PCB like that:
The Pull-down resistor on Pin 2 is removed and a Pull-up resistor is soldered
between the hot terminal of the Pullup resistor for MODE and the free terminal,
in order to use the I2C mode a shortcut between pin 27 and 28 of the codec is needed
and the SDA/SCL termination can be connected to pin 15 and 14 of the Daisy, but is such case I2C4 is to be used instead of I2C2.
73 de Claudio SA0PRF
1 Like
Hi,
I had asked to bring in the designation “D31” into the datasheet for the LED, because this pin number is used in the Arduino environment.
In my opinion it’s a great weakness for Daisy, that Arduino is only usable for <128kB for Daisy, which makes it useless effectively. Pure CPP might be the language flavour for professional programmers, but Arduino is made for non-professionals and is more easy to learn, especially if you have already worked with other Arduino based systems. There are so many great resources like tutorials about Arduino…
I’ll let you in a small secret: the die used for STM32H750xx is the same series as its bigger siblings, and probably physically the same.
I’ve tested mine and it has a full 2 MiB flash, same as an STM32H743II (or 753II).
This is quite common with STM32s, no extra M4 core though (missing Access Port in the debug system, at least).
Of course, one needs to lie to the probe/debugger for flashing, and that it works reliably is anything but guaranteed. Use at your own risk.
I’d like to just clarify that the circuit in the datasheet is an example of how to connect an additional, external codec to the daisy using the available SAI pins.
This configuration is similar to, but not identical to the configuration used for the on-board codec. The two primary differences are:
- that the typical application example recommends using +5V for the analog VCC.
- The MODE pin is configured to use the differential outputs, which is how the chip should be configured to work with TI’s typical application output circuits that can be found on page 40 of the PCM3060 datasheet.
The latest version of the datasheet has the specifics of the internal codec’s configuration.
The I2C control over the codec was intentionally not added to the rev7 version of Daisy to preserve backwards compatibility so that with existing code, the device would register as a rev4 daisy, and still function as expected. With PB11 connected, the rev4 software detection would result in the de-emphasis pin on the PCM3060 becoming active, resulting in unwanted filtering of the audio output.
Hope that makes clear why the on-board codec is configured the way it is.
1 Like
Good catch. That’s correct. We’ll get that updated as well.
Hi Stephen,
the HW design is yours and you have chosen how it shall work, nothing to say about that.
What I am about is that the Daisy Seed is a rare combination of a good CPU with DSP capability and a good Coded with a reasonable price, so that it would be great to have a bit of more flexibility.
I have nothing against having the default configuration in HW MODE.
On the other hand you can select differential output by setting S/E bit in register 64 if you wish, once you can use I2C. Furthermore with I2C you can fully use the input gain control etc.
Still, I don’t understand why libDaisy says that setting PB11 to zero is for disabling deemphasis when PB11 is not connected at all, and why PH4 is connected to MC/FMT/SCL since in HW mode it can change the format from 24bit left justified (default) to I2S.
By the way, when having a 220k Pull Up on MODE pin, the output is Single Ended, that is what I see on my board.
You’re looking at the code for DAISY_SEED_2_DFM, which is not generally available (yet?). It is different from the Daisy Seed.
I am reading the official libDaisy that has been automatically installed when setting up the toolchain for Linux.
// Device-based Init
switch(CheckBoardVersion())
{
case BoardVersion::DAISY_SEED_1_1:
{
// Data Line Directions
sai_config.a_dir = SaiHandle::Config::Direction::RECEIVE;
sai_config.pin_config.sa = {DSY_GPIOE, 6};
sai_config.b_dir = SaiHandle::Config::Direction::TRANSMIT;
sai_config.pin_config.sb = {DSY_GPIOE, 3};
I2CHandle::Config i2c_config;
i2c_config.mode = I2CHandle::Config::Mode::I2C_MASTER;
i2c_config.periph = I2CHandle::Config::Peripheral::I2C_2;
i2c_config.speed = I2CHandle::Config::Speed::I2C_400KHZ;
i2c_config.pin_config.scl = {DSY_GPIOH, 4};
i2c_config.pin_config.sda = {DSY_GPIOB, 11};
I2CHandle i2c_handle;
i2c_handle.Init(i2c_config);
Wm8731::Config codec_cfg;
codec_cfg.Defaults();
Wm8731 codec;
codec.Init(codec_cfg, i2c_handle);
}
break;
case BoardVersion::DAISY_SEED_2_DFM:
{
// Data Line Directions
sai_config.a_dir = SaiHandle::Config::Direction::TRANSMIT;
sai_config.pin_config.sa = {DSY_GPIOE, 6};
sai_config.b_dir = SaiHandle::Config::Direction::RECEIVE;
sai_config.pin_config.sb = {DSY_GPIOE, 3};
/** PCM3060 disable deemphasis pin */
GPIO deemp;
deemp.Init(Pin(PORTB, 11), GPIO::Mode::OUTPUT);
deemp.Write(0);
}
break;
case BoardVersion::DAISY_SEED:
default:
{
// Data Line Directions
sai_config.a_dir = SaiHandle::Config::Direction::TRANSMIT;
sai_config.pin_config.sa = {DSY_GPIOE, 6};
sai_config.b_dir = SaiHandle::Config::Direction::RECEIVE;
sai_config.pin_config.sb = {DSY_GPIOE, 3};
dsy_gpio_pin codec_reset_pin;
codec_reset_pin = {DSY_GPIOB, 11};
Ak4556::Init(codec_reset_pin);
}
break;
}
1 Like
Thank you for that secret! 
Daisy Seed has lots of Memory. The Problem for me is, that I don’t have enough knowledge about the internals of Arduino to “lie” to it well. - If you have ideas, we could discuss this more in Arduino: How to use 512k Ram area for program space? - Arduino - Daisy Forums (electro-smith.com).
That code shows that B11 is connected to pcm3060 deemphasis on the DFM. On Daisy Seed, it shows that it should be connected to codec reset pin, which is 15 on pcm3060.
It says that it’s connected to reset pin of Ak4556.
Is it connected to reset pin of pcm3060 on DAISY_SEED_1_2? Where’s it written?
And why PH4 is connected to MC/FMT/SCL?
I won’t attempt to explain WHY things are this way, it might just be errors from when the design was changed to use pcm3060. The comments in the code are somewhat misleading, also.
The important point is that the Rev7 board (also known as Daisy Seed 1.2) doesn’t have board identifying pins, so CheckBoardVersion() identifies it as DAISY_SEED. ```
Ak4556::Init(codec_reset_pin) is safe on pcm3060 because it doesn’t do anything but toggle the reset pin.
1 Like
Thanks for the information!
That´s true, I pointed out that the Rev7 is detected as DAISY_SEED some days ago: https://forum.electro-smith.com/t/rev-7-seed-is-detected-as-rev-4/4876
The issue is that the latest datasheet (V1.1.2) still erroneously says that PD5 is tied to GND to indicate Rev7, whereas it is not, at least on the board I have (could it be a faulty unit?).
Neither PD3 nor PD4 are connected to GND in revision Rev7. Neither is PD5, which according to the DS datasheet V1.1.2 is the one that should indicate revision Rev7.
Since they have decided not to publish the schematics (silly in my opinion) they should at least have more accurate documentation.
2 Likes
Be careful, sometimes the chip is classified as one part or another depending on the tests it passes. Part of the flash could be damaged.
PD5 is connected to GND on the Rev7 hardware.
libDaisy does not yet have any built-in software detection for the Rev7, and no specific software initialization is required for the rev7 hardware to operate correctly (unlike the transition from the rev4 to either the rev5, or the upcoming Seed2 DFM board).
The fall-through for Rev4, and in this case the Rev7 Audio Initialization does strobe PB11, which on the rev4 hardware was connected to the reset pin of the AK4556.
On the Rev7 hardware this pin is disconnected from the codec. So the Ak4556::Init function does not have any effect on the hardware.
If you need your software to specifically identify the Rev7 hardware prior to any built-in software detection being added to libDaisy, here’s an example of how to do so (I double checked that this behaves as expected with both a Rev5, and a Rev7 Daisy):
#include "daisy_seed.h"
using namespace daisy;
DaisySeed hardware;
int main(void)
{
hardware.Init();
hardware.StartLog(true); /**< wait for serial connection */
GPIO detect;
detect.Init(Pin(PORTD, 5), GPIO::Mode::INPUT, GPIO::Pull::PULLUP);
if(!detect.Read())
hardware.PrintLine("This is Rev7");
else
hardware.PrintLine("This is not Rev7");
while(1)
{
/** Blink LED to show program is running (this indicates to
* the user that the Serial Monitor Connection has been established) */
hardware.SetLed((System::GetNow() & 1023) > 511);
}
}
If you have a rev7 board that ends up printing, “This is not Rev7” that is actually a defect that some how passed through our QC tests.
2 Likes
Of course, as I pointed out there’s no guarantee it works reliably.
Especially flash characterisation is relatively expensive and time consuming, so that’s a prime choice to cut costs for a “value-line” MCU.
Fine for a home project (and the seed has got that nice fat QSPI flash…), a no-no for a real product.
In the wild, you do find cheap stuff where this is (ab)used, one of the most common are the cheap ST-Link V2 clones from eBay or AliExpress: they often use an STM32F101 instead of the STM32F103
The specific F101 used ha less flash (the probe image does not theoretically fit) and, even more important, has no USB, at least on paper!
Thanks Stephen, I had modified the original detection function to test PD5 instead of PD4, but got “DAISY_SEED”. I also tried your code just in case and got “This is not Rev7” This indicates a defect in my board, but there is no point in sending it back, I will continue to use it knowing it is Rev7 even if it says otherwise.
In any case, your code will be useful for anyone who needs to check the revision for whatever reason.