bajelly

Members
  • Content Count

    5
  • Joined

  • Last visited

  • Days Won

    1

bajelly last won the day on July 13 2018

bajelly had the most liked content!

About bajelly

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. To close the loop: I was actually able to solve the problem and now have a small IP Core that initializes the sound chip and sends samples (latched in via the simplest bus, should be compatible to AXI4 Stream) to play them. All in the FPGA fabric, without any external support needed, so that's neat. Unfortunately, I don't really remember what the problem was. I changed the initialization sequence a bit to be closer to a (microprocessor) example that I found online and it started working. It was a bit puzzling, though, since what I did seemed perfectly legal according to the data sheet. If there is some demand, I can clean up the code and put it up online, in case you want to play sound without microprocessor support.
  2. Thanks for the suggestions and explanations. As soon as I have time for it, I will try to get an existing project running to confirm that the chip is indeed working and to look at the signals if it is. I will also double check that my I2C initialization does work, by reading back the registers. Other than that, does my approach to try to dump some pseudo-random data (using an LFSR for example) be a viable way to see if I can make the chip produce some sound? The theory behind this is that even if I really mess up slicing the data into samples, as long as it still produces random-ish samples there should always be some very audible sound in (theoretically) all of the frequency spectrum. While with a tone, it's somewhat easier to accidentally produce an inaudible signal (e.g. using 0x0000 and 0xFFFF which hamster just mentioned).
  3. Much more fun I am pretty sure my I2C logic actually works. I latch any ack failure on an LED and I've looked at the signals through a logic analyzer core in detail. Also, at some point I was so desperate that I instead connected the I2C signals to the PS, and used I2C-tools to set the registers from the command line. I will double check again... Hmmm. But even if I messed that up, shouldn't I at least get something? In theory, random data should contain energy across all frequencies of the spectrum, no? Unless I was so unlucky that in every try where I got the register values right, I somehow messed my 2kHz tone up in a way that shifts it to inaudible frequencies... Actually, maybe I should produce random data instead of a 2kHz tone, that's more unlikely to be messed up completely inaudible! Nonono, I am actually pretty sure the clicking and hissing I hear is only attributable to powering the device on and routing the analog inputs to the output... Literally nothing changes if I turn my data stream off, so I think my digital data is completely inaudible. I started out with a 2kHz WAV that I put into a ROM IP Core in my design. I messed actually putting that down into samples a lot, but deliberately because I only wanted to hear something for starters, and fix my LR multiplexing up later. But I literally hear nothing. I think I could recite it in my sleep by now 8) Anything helps! Though the sample initialization code that I saw and that is supposed to work on the Zybo doesn't really do anything different from what I do... That is actually a very good idea. I will try to get some demo project working and see if it does anything. If not, my chip is toast. If it does work, I can see if I spot any difference in the initialization or the I2S logic traces... Thanks so far!
  4. Thanks. I already found that thread, but I don't think it's completely related. The thread mainly talks about how to get the audio chip working with Linux. In my case, Linux is not relevant at all, everything is done from the PL. In fact I'm trying not to use the Processing System at all, the only time I did was to use i2c tools from Linux to directly set the registers that way, as a debugging help. Any Linux drivers are not involved. Basically my question simply boils down to: What, exactly, do I need to do to actually use that chip's DAC to produce some audible sound? I am almost beginning to suspect that the chip might be broken... but it's probably just my fault.
  5. After trying about everything I could think of, I am still not able to produce any sound through the DAC on the Zybo's audio chip. I tried initializing the chip via I2C using what I think are the proper register values and the proper power on sequence, both using a core I wrote myself, and alternatively by connecting the I2C interface through to the Processing System and using Linux and i2c-tools there to set the register values from the command line. My initialization sequence includes activating the digital core (R9), enabling the DAC by setting DACSEL, unmuting the DAC, powering on both before (without Out) and after (with Out) setting the other registers and with the proper delay, and many more things. I am also pulling the active-low MUTE pin high using "i2c_m_mute <= '1';" in VHDL. I can make the chip pop and hiss by powering it on, and I think I can manage to put Line In or Mic onto the output with the right register values (not entirely sure since I had no Mic laying around, but I'm relatively sure I heard something when I improvised with some ear buds). Overall, there's strong indication that my initialization sequence is at least partially successful, but the DAC remains entirely silent. For the I2S signals, I have a 12.288MHz MCLK fed by a Clock Wizard, a 48kHz PBLRC clock, a 3.072MHz BCLK (for 64 cycles per 48kHz sample, but I also tried using half of that since I am only trying to feed 16bit data) and PBDAT aligned to that. I verified both with an ILA core and with an oscilloscope directly at the chip pins that the signals are there and look sound. Yet I cannot even make the chip produce anything digitally. Even if PBDAT is screwed up, it should at least produce some sort of random noise or clicking, no? What am I missing? Since I'm very new at FPGAs, this may be something entirely obvious. Attached is an example of what is going on on the I2S wires. I tried at least left justification and the I2S format. This is with a BCLK for 32 bits per sample (i.e. 16bit per channel), as mentioned above I also tried using a 64bit BCLK with no effect.