Terence D

  • Content Count

  • Joined

  • Last visited

About Terence D

  • Rank

Recent Profile Visitors

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

  1. Okay, so I've got fully working code for the STM32F411 which has a CS43L22 DAC on the board. Note that this is not the same as the CS4344 that is on the PmodI2S. The CS43L22 has a whole set of initialization steps that the CS4344 does not and also does communication with I2C and I2S. I still want to get the PmodI2S working with my STM32F429. My next steps are going to likely include: Comparing my STM32411/CS43L22 code with my STM32F429/CS4344 code and making tweaks to the latter. Getting DMA to work first with the STM32411/CS43L22 and then hopefully leveraging this information to get DMA to work with the STM32F429/CS4344. If anyone is interested in my ongoing trials and tribulations with the above please let me know.
  2. Good insights, thanks, Stephen. Some thoughts on each one of your points (with respect to your original numbering): 1) Based on this blog entry it sounds like you can use lower sample rates. Specifically the quote: "Note that you are not required to use the maximum bit rates for this chip. You can send in lower bit rates as long as the LRCLK to MCLK ratio is within the following ratios as required by the CS4344". Additionally, on page 2 of the Digilent PmodI2S documentation it says "A table of commonly used sample rates and their corresponding MCLK rates from the CS4344 datasheet is provided below". I was hoping this meant that I could use different sample rates. I use 8KHz because that is the only sample rate shown in the STM32F4 datasheet table which requires a master clock yet has no error: 3) Good suggestion! I tried this, and the funny thing is that this is that the audio tone just increases. Which makes sense in a way that it's less instructions per sample - i.e. instead calling the same chunk of code for each sample it should only have to call it for x samples (x being the third argument to HAL_I2S_Transmit - I tried various values). However, I would suspect the SPI data register would "block" at a periodic rate specific to my 8 KHz sample rate, which is why I find the pitch shifting much higher odd. 4) Another good suggestion! As an experienced software engineer I should know much better than to not check the return code. For some reason I didn't realize the HAL_I2S_Transmit was returning a result. So, I'm doing very similar to what you suggested: I'm simply toggling a GPIO pin when a none HAL_OK return code is obtained. And it was definitely getting toggled frequently when viewing with my logic analyzer. With farther tweaking I see it's frequently returning a HAL_TIMEOUT error code. Changing the timeout parameter passed to HAL_I2S_Transmit to a larger value causes this error to go away but then audio output is either non-existant or even farther distorted. Based on what I've found in item 3 above I'm thinking there is something fundamental I'm missing with how I2S works on the STM32 board. I've (just now) managed to get a hold of a similar STM32 board (an STM32F411) that actually has an very similar DAC on the board itself and have an audio example from STM working on this board. I'm going to dig through the code and fully understand how that works in hopes of it shedding some light on how to get the STM32F429 to work with the Digilent PmodI2S. I've made myself a reminder (a week out) to return to this thread and post my results. Stephen - Thanks for all your help with this so far. You've been very helpful and I very much appreciate it. -Terence
  3. Thanks Stephen - Great reply! Really appreciate your interest in helping me with this. I actually have a "sister thread" going on at the STM32 MCU forum here. A forum user over there replied overnight similar to your suggestion - that there might be something going on in how timely I'm sending the data to the SPI register. I've just replied to that post including details. Basically I'm using the STM32 hardware abstraction layer API to send the sine wave data to the SPI (I2S) data register. This is occurring in the main while loop of the program (the while loop that occurs after setup is complete). There is no other processing or any interrupts, but essentially, this is a "polling" operation. Here's the code if interested: while (1) { if (HAL_I2S_GetState(&hi2s2) == HAL_I2S_STATE_READY) { HAL_I2S_Transmit(&hi2s2, &SINE_TABLE[index], 1, 0); if(!channel) channel = 1; else channel = 0; if (channel) { index++; index = index % 256; } } } And, as I mention on the "sister thread": Possibly I need to offload the data transfer duty to DMA? I have not yet done DMA with this development board (STM32F4) I have done it with a different ARM Cortex-M4 board though (the Texas Instruments TM4C123G). I cannot use the TM4C123G for this though as it does not have I2S support. I think my next plans of action are as follows (in order): Not use the HAL to transfer the audio data but write directly to the SPI data register inside the while loop and see if the issue is resolved. Attempt to use DMA to transfer the audio data instead of the infinite while loop. Let me give at least action #1 a try and report back. Achieving action #1 should take minimal time. Action #2 is likely going to take substantially longer, however, I did plan to work my way up to using DMA for audio transmission with this board anyway, so I suppose there is no time like the present to get started Thanks again, Terence PS: Using FPGA's to do audio processing sounds AWESOME. Hope to work my way up to this before long.
  4. Stephen - Apologies for the late reply. I spent a good bit more time understanding the clock configurations on my MCU and I now have better I2S clock signals going from the my STM32F429 MCU to the Digilent Pmod2S DAC as shown below. No random signals showing up that I had before: I've configured the I2S to be just a sample rate of 8 KHz and am sending the same 256 sample cycle of a sine wave from the MCU to the Pmod2S. The sine wave sounds good EXCEPT for random "clicks" - maybe 5 to 10 per second. Here is an example of such a "click" I've obtained using my oscilloscope: Similarly, I've recorded the audio coming out of my speakers with a mic. Here is an example of the "click" when viewed in Audacity (audio editor software): As far as I can tell I have everything configured correctly, so I'm not sure what the issue is. Any thoughts on your end would be very welcomed. Thanks, Terence
  5. Hi Stephen - Thanks again for your thoughts. Having someone question my setup (other than myself) is very helpful. Specific answers to your questions: I've scoured the web with my best Google-Fu and the best I've been able to find is the example I've been using so far from here. ...Since finding this, I've actually learned about the STM32CubeMX application. It's a software application tool for STM32 boards that allows you to visually configure peripherals and clock speeds and the will generate code with the given configuration. I've used this to configure the clock and setup the I2S and now no longer have random glitches on the LRCK. However, my output signal is very distorted. As an example of how distorted, see the audio waveform screenshot below. To make analysis simpler, I've switched from outputting a sine to a sawtooth. The sawtooth is at 1,000Hz. The sample rate is 48,000 Hz. So I simply have 48 samples that go from the lowest 16 bit value to the highest. I have an Embedded Artists LabTool. I've only used it as a logic analyzer, but it does have two oscilloscope inputs. Sorry, stupid question: How exactly do you analyze an audio output signal with an oscilloscope? The PmodI2S has a typical 1/8" stereo output jack. I know that I can only monitor one of the stereo channels (left or right) with the oscilloscope. I have a 1/8" stereo wire plugged into the PmodI2S. This wire has a male adapter on one end and spliced wires on the other. Looking at the stereo cable, each channel has two separate wires associated with it - I suspect a positive and a negative. Not sure which should be hooked up to the LabTool's oscilloscope single wire input... Any suggestions would be appreciated. Attached is the latest logic analysis of all four lines from the new program generated using the STM32CubeMX. I just took this now for the first time and clearly the MCLK doesn't look right... I would think the duty cycle should always be 50%... I will look into this right after this post. Hmmmm... The transmit function of the STM32 HAL API takes uint16_t as it's data. I first generate this data with an audio editor. Then I use a simple C program to display the data as a c array. Below are examples of my sawtooth cycle as both an unsigned int array and signed int. When using either of these the output from the speakers sounds and appears identical - same as that shown in the screenshot of the waveform below. uint16_t sawtoothUnsigned16bit[48] = { 0x0, 0x555, 0xaab, 0x1000, 0x1555, 0x1aab, 0x2000, 0x2555, 0x2aab, 0x3000, 0x3555, 0x3aab, 0x4000, 0x4555, 0x4aab, 0x5000, 0x5555, 0x5aab, 0x6000, 0x6555, 0x6aab, 0x7000, 0x7555, 0x7aab, 0x8000, 0x8555, 0x8aab, 0x9000, 0x9555, 0x9aab, 0xa000, 0xa555, 0xaaab, 0xb000, 0xb555, 0xbaab, 0xc000, 0xc555, 0xcaab, 0xd000, 0xd555, 0xdaab, 0xe000, 0xe555, 0xeaab, 0xf000, 0xf555, 0xfaab, }; int16_t sawtoothSigned16bit[48] = { 0x8001, 0x8556, 0x8aab, 0x9000, 0x9555, 0x9aaa, 0x9fff, 0xa554, 0xaaa9, 0xaffe, 0xb553, 0xbaa8, 0xbffd, 0xc552, 0xcaa7, 0xcffc, 0xd551, 0xdaa6, 0xdffb, 0xe550, 0xeaa5, 0xeffa, 0xf54f, 0xfaa4, 0xfff9, 0x54e, 0xaa3, 0xff8, 0x154d, 0x1aa2, 0x1ff7, 0x254c, 0x2aa1, 0x2ff6, 0x354b, 0x3aa0, 0x3ff5, 0x454a, 0x4a9f, 0x4ff4, 0x5549, 0x5a9e, 0x5ff3, 0x6548, 0x6a9d, 0x6ff2, 0x7547, 0x7a9c, };
  6. The STM32F429 has the choice of configuring the I2S communication using the PLL or SAI. It seems like the PLL is the more frequent choice so I'm using it. Using my logic analyzer to view the MCLK and LRCK lines I see that the MCLK to LRCK ratio is very close to being right (256:1). I've attached a screenshot of this below. The MCLK cycle is roughly 80 nanoseconds and the LRCK cycle is roughly 20 microseconds. My logic analyzer's peak sample rate is 50 MHz so I'm limited in getting measurements with higher precision than this. My I2S sample rate is set to 48,000 Hz which should mean a sample roughly every 20 microseconds (i.e. what the LRCK is roughly showing). The odd thing I'm seeing are random logic changes in the LRCK as shown in the screenshot below. These don't happen every sample but happen maybe ten or twenty times per second and result in glitch sounds in the audio output. As mentioned I'm thinking my problems rest with my clock configurations. The clock configuration in the STM32F4 is not trivial. I have a separate thread in the STM forum where I've been trying to fully understand this. If interested, this thread is here.
  7. Hi Steve - Thanks for the reply. Currently I'm simply trying to send a sine wave from my STM32F429 Discovery board to the PModI2S DAC. In the program that runs on the STM32F429 I have a simple array of 256 uint16_t values that make up a single cycle of a sine wave. I continually loop through this array sending the values to the PModI2S. At a sample rate of 48000 Hz, the audio output from the PModI2S to the speakers hooked up to it should be a 187.5 Hz sine wave. When I do get audio (as I tweak various clock and I2S settings in the program running on the STM32F429) I'm getting audio that is far off from that that 187.5 Hz tone I expect I should be getting. This is why I'm quite certain it's related to my clock settings in the program. Any suggestions on your end would be welcome. Thanks for your continued interest in helping me get this figured out. -Terence
  8. That's AWESOME!!! I'd love to get into audio processing w/ FPGA's but have my hands full with Cortex-M boards right now. So, good news: I got the PModI2S outputting audio. The audio is that of a single sine wave cycle that loops infinitely. Bad news: I don't have the clock settings quite right still and the pitch of my sine wave coming out of the speakers hooked up to the PModI2S is not quite right. I'm fairly certain the issue is properly configuring the clock settings on the STM32F... Which is not trivial. I'm confident I'll get it figured out though with some more work which I should be getting to shortly. If anyone is interested in my code to make this work please let me know and I'll come back and post a link here once I have it working 100% correctly.
  9. Hi Stephen - Thanks for the information. I just looked at figure 7 of the CS4344 datasheet and see what you're saying. Unfortunately, I never got the PModI2S working with my TM4C123G board. I instead switched to another DAC at the time. HOWEVER, funny timing, I've been playing around with a new board - an STM32F429 Discorvery board that actually has I2S support (unlike the TM4C123G) and I've just in the last few days started working with the PmodI2S again trying to get it to work with the STM32F429. Please correct me if I'm wrong, but I imagine the 1 bit delay between the edge of the LRCK and the MSB of the SDATA is standard for I2S communication, right? Thanks in advance, Terence
  10. @[email protected] - Thanks so much for your reply. Yeah, I definitely should've looked closer at the CS4344 datasheet. For whatever reason I got overly focused on the Digilent documentation. Thank you for pointing out that the SCLK is an input. As for the sample rate, my problem is that with the Tiva LaunchPad TM4C123G I believe the fastest clock I can send out a pin is 25 MHz and then fractions of that. For example, the next fastest being 16.667 MHz, then 12.5 MHz, then 10 MHz and so forth. I happened to come across this blog post where the author used a non-standard sample rate with the PMODI2S. My understanding is the MCLK just has to be a 256x, 384x, etc multiplier of the LRCLK and it could work with any sample rate (I'm of course open to the idea that I may be incorrect with regards to this functionality). I have a pretty good understanding of DSP fundamentals and a lot of experience with digital audio. I would prefer to have an audio output sample rate of 44.1KHz but I'd first just like to get the chip to work at any reasonable sample rate (my definition of "reasonable" being maybe 20KHz or higher) and then go from there to see if I can improve the sample rate. I'm going to carefully study the CS4344 datasheet and see what additional insights I might be able to glean. I'll gladly post back when I've made more progress. Again, much appreciate your reply. -Terence
  11. Hi - I've recently purchased a PMODI2S which I'm trying to use with my Tiva LaunchPad TM4C123G. The TM4C123G doesn't doesn't have I2S, but TI has a good document of how it can be emulated using dual SPI's. I've setup the PMODI2S inputs as follows: Pin 1 (MCLK) - Sending a 6.25 MHz 50% duty cycle signal from the TM4C123G to the PMODI2S Pin 2 (LRCLK) - Sending a 24.4141 KHz 50% duty cycle signal from the TM4C123G to the PMODI2S (This is 1/256th of 6.25 MHz) Pin 3 (SCK) - I have hooked up to my logic analyzer and see no signal output Pin4 (SDIN) - I do not yet have this hooked up to anything Pin 5 (GND) - Hooked up to the GND pin of my TM4C123G Pin 6 (VCC) - Hooked up to the +3.3V of my TM4C123G After reading the PMODI2S reference manual it's my understanding I should be seeing an output signal from the PMODI2S on the SCK pin. Can anyone confirm my understanding is correct? Thanks.