STM32Cube USB Audio class driver bugs

[gory-mail]

Posted on November 21, 2014 at 13:11

Hi!

I've ported the Audio Speaker demo from SMT32F4xx-G Evalboard to STM32F4-Discovery. I found some strange things during that. There is a function in the driver strucure with two possible parameters that can send the audio to the I2S DAC:   AUDIO_COMMAND_START which invokes  BSP_AUDIO_OUT_Play   AUDIO_COMMAND_PLAY  which invokes BSP_AUDIO_OUT_ChangeBuffer Here is the function/**   * @brief  Handles AUDIO command.           * @param  pbuf: Pointer to buffer of data to be sent   * @param  size: Number of data to be sent in bytes   * @param  cmd: Command opcode   * @retval Result of the operation: USBD_OK if all operations are OK else USBD_FAIL   */ static int8_t Audio_PlaybackCmd(uint8_t *pbuf, uint32_t size, uint8_t cmd) {   switch(cmd)   {   case AUDIO_CMD_START:     BSP_AUDIO_OUT_Play((uint16_t *)pbuf, size);     break;     case AUDIO_CMD_PLAY:     BSP_AUDIO_OUT_ChangeBuffer((uint16_t *)pbuf, size);     break;   }   return 0; } The comment says we need to pass the size parameter in bytes, and is used that way in upper layers, so clear so far. However in the BSP packages I can see that these two functions are used different size parameters for the DMA: BSP_AUDIO_OUT_Play uses a division by the sample bitdepth which is correct if we passed the number of  bytes (not samples) to the previous function.HAL_I2S_Transmit_DMA(&haudio_i2s, pBuffer, DMA_MAX(Size/AUDIODATA_SIZE)); BSP_AUDIO_OUT_ChangeBuffer uses the number of bytes and not have the dvision by 16bits, so it cannot be correct. HAL_I2S_Transmit_DMA(&hAudioOutI2s, pBuffer, Size); Can anyone tell my what is the reason behind, or is it just a bug? Thank you.

[gory-mail]

Posted on November 21, 2014 at 17:39

Another thing I don't really understand about how DMA is used in usbd_audio_if.c file.

There is an interrapt for the DMA half complete which is: /**   * @brief  Manages the DMA Half Transfer complete event.   * @param  None   * @retval None   */void BSP_AUDIO_OUT_HalfTransfer_CallBack(void) {   USBD_AUDIO_Sync(&USBD_Device, AUDIO_OFFSET_HALF); } But in the USBD_AUDIO_Sync function a new DMA request is issued for I2S. What is the sense of this? I thought you cannot issue another DMA while the previous is not completed. So I think this one should have no effect, however the example application seems to be working fine.

[mrjaner]

Posted on November 25, 2014 at 09:14

if you will port some codes from SMT32F4xx-G Evalboard to STM32F4-Discovery, you need very big time. They wrote every project very specific, nobody didnt think that someone will use them for another STM32 platform. 

[gory-mail]

Posted on November 25, 2014 at 12:55

These things are not just for Discovery board. These are present even in the original example with the original G_EVAL  board.

Actually it is not a very big work to port to the Discovery board. It took me 1-2 hours. But the audio driver has nothing to do with the board itself. It is general.

[Montassar BEN ROMDHANE_O]

Posted on November 25, 2014 at 15:18

Hi,

You can refer to this [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F4Discovery%20Cube-based%20USB%20Speaker%20application%20not%20working&currentviews=171]post. The same USB_Device/AUDIO application is ported from STM324xG_EVAL to STM32F4-Discovery successfully. Remember that STM32Cube HAL portable APIs allow easy, and fast migration of user application accros different STM32 families.Regards,Heisenberg.

[gory-mail]

Posted on November 25, 2014 at 15:29

Hi,

Thanks for the link. As I mentioned, I easily ported the application, so this is not the problem. The problem is with the original application, if you read my first two posts again. There are some inconsistent use of functions as you can see in them.  - I2S gets double the amount of data it needs as I mentioned in my first post.  - A new DMA request is issued during DMA Transfer Half complete IRQ, which has no effect in my opinion. Besides that, I think the audio synch function has also some issues, and other functions like Data_Out. However I corrected all these functions, and the also packet size for of DMA, and works fine for me. I just wanted to inform you about there is something wrong going on USB Audio class driver and BSP packages. Thanks Gergely

[AME MCU Support Center BB]

Posted on January 29, 2015 at 15:00

Hi Gorcs,

You are right about the inconsistency in BSP_AUDIO_OUT_Play() and BSP_AUDIO_OUT_ChangeBuffer().The former uses size as the number of bytes and the latter uses size as the number of half samples.Both should use either the number of bytes or the number of half samples to avoid  the inconsistency.Regarding your second point, you are right. It is not possible to generateDMA request in half transfer complete.What's wrong with Data_Out ?With regards,