STM32H753I-EVAL2 - Using Ux_Device_Audio2.0_Playback does not work

[audio]

I have STM32H753I-EVAL2 board and I want to set it up as an USB Speaker device. 

I see 3 protect that can make this as such, which are:

Name	Board	Board Type	STM32CubeMX Version	SW Package Installed
Ux_Device_Audio_2.0	STM32N6570-DK	Nucleo-64	NA	TRUE
Ux_Device_Audio_2.0_Standalone	STM32N6570-DK	Nucleo-64	NA	TRUE
Ux_Device_Audio2.0_PlayBack	STM32H743I-EVAL	Nucleo-64	6.15.0	TRUE

Two things...

1) I don't want RTOS, but STM32H743I-EVAL has RTOS, and the one I'm looking for is on the wrong board. So... What advantage do I have using RTOS? Can I use the Standalone one and change the board somehow in the code? I haven't done much comparison to know, I've been overwhelmed trying to understand the organization of the project. 

2) When I do download, install and run the Ux_Device_Audio2.0_PlayBack anyway, the program is running. I see the USB being enumerated as a speaker on my laptop. Issue is, everything is fine, but when I try to play an audio, it runs into a fault -- > `void HardFault_Handler(void))`

I can't tell where it's being called, but the stack is as such:

Any idea why I can't play audio out?

[FBL]

Hi @audio 

We need to check which board revision do you have, the link you provided doesn't help on this! You can check on the bottom of the board, and check under CAD resources, Schematic Pack, it should be EVAL2 for the MB1246 RevE board with STLINK-V3E, read carefully the user manual for any hardware changes. 

Note, the example provided has been tested on H743 Eval board and works on my end using H757 eval B05 as well !

[audio]

Hello @FBL 

Thank you for your reply and sharing your screenshot. 

I checked the board, it is indeed MB1246. It does have the STLINK-V3E as you mentioned. 

I have to ask, the example code says this is compatible on H753I-eval2 but it is advertised for H743I-eval, I wonder if it is using the wrong board (i.e. H743 and not H753) and therefore it accessed the wrong memory location?

How can I ensure it's running on the right board? I outlined my steps on how I downloaded and built the example code in the previous reply, did I miss a step there?

[FBL]

Hi @audio 

It's possible hardware differences between H743 and H753 boards (memory layout, peripheral clocks, BSP drivers) can cause issues such as accessing invalid memory addresses, leading to HardFaults.

• Check the linker script (*.ld file) and memory section addresses to confirm they match your STM32H753I-EVAL2 RAM layout.

.usbx_data 0x24020000 (NOLOAD):
  {
    *(.UsbHpcdSection)
  } >RAM_D1

  .usbx_bss 0x24021000 (NOLOAD):
  {
    *(.UsbxPoolSection)
  } >RAM_D1
  
  .audio_stream_buffer 0x24040000 (NOLOAD):
  {
    *(.AudioStreamBufferSection)
  } >RAM_D1

 Attached full project working on MB1246 eval board rev B05 in standalone mode.
Updated project !

[audio]

Thank you @FBL 

Comparing Linker script

I did the diff between the STM32H743XIHX_FLASH.ld and STM32H753XIHX_FLASH.ld, and the difference is what you pointed out (that code script you pasted is in H473 but not in H753). 

However, there is no STM32H743XIHX_RAM.ld for me to compare the STM32H753XIHX_RAM.ld to. 

I am new to this technology so I am learning, so forgive me if I am ignorant.

Changing MCU

I followed the  UM1718, tutorial 5 to try to change the MCU, and imported it. Unfortunately it won't run as it removed a lot.

Provided Attached Project

Thank you for sharing the project file, however, after cleaning, building caused some issues: 

At this point, however, I should be able to compare the two projects and see what changes you made to make it a standalone, that should allow me to build it successfully in the newer project. 

[audio]

RE: Comparing Linker Script

Okay, so I finally understood what the linker was.

When I switched out the H753 linker (Flash.ld), I had to link it in the Properties settings, and tested it. The audio played wasn't very clear, so I added the code you pasted here (.usbx_data), and now it's clear. 

I've also changed the startup file just to be safe.

So consider the Linker script "solved". 

Audio Looping Persists

However, the looping at the end still persists. I think I figured it out. If I add few seconds silence at the end of the audio file, there's no looping, and there's also no screeching in the first few seconds. You can probably test this by pausing/stopping the audio player while it is audible, and you'll probably notice that the audio loops, and then press play and you'll hear the screeching sound. I don't think that's supposed to happen, let me know if this is reproducible on your side (and your solution to this).

RE: Changing MCU

I kept the existing project of the Ux_Device_Audio2.0_PlayBack (reverted all changes), and changed the two files I mentioned above - see here: 

I am not sure what the best practice is, but that's what I did. If there's a safer/better way to do so, please let me know. As for the blue question mark, I assume it's safe to keep it there even though I work with H753 (screenshot shows H743). If this is acceptable, consider this change "solved".

[FBL]

Hi @audio 

About Audio looping persists, I confirm the same behavior on my end! You can implement BSP_AUDIO_OUT_Pause() to pause the DMA stream feeding audio data to the codec.

VOID USBD_AUDIO_PlaybackStreamChange(UX_DEVICE_CLASS_AUDIO_STREAM *audio_play_stream,
                                     ULONG alternate_setting)
{
  /* USER CODE BEGIN USBD_AUDIO_PlaybackStreamChange */

  if (alternate_setting == 0)
  {
    // Pause audio output when stream is closed
    BSP_AUDIO_OUT_Pause(0);
...

[audio]

Hello @FBL 

This solution is not solved, I did not mark it solved. Please remove the status "solved".

Adding the  BSP_AUDIO_OUT_Pause(0); did not solved the problem, instead, no sound is produced. If I commented this line out, it works, but the audio looping persist with the high screeching in the first 4 seconds. 

I have cleaned and rebuilt and it is still the same result. I even went back to the original example, and the program goes into hardfault if I don't change the == into >= in line 5 below of ux_device_audio_play.c:

 if (length)
  {
    BufferCtl.wr_ptr += frame_length;

    if (BufferCtl.wr_ptr >= AUDIO_TOTAL_BUF_SIZE) //THIS LINE IS CHANGED
    {
      /* All buffers are full: roll back */
      BufferCtl.wr_ptr = 0U;

      if (BufferCtl.state == PLAY_BUFFER_OFFSET_UNKNOWN)
      {

        /* Start BSP play */
        BufferCtl.state = PLAY_BUFFER_OFFSET_NONE;

        /* Put a message queue  */
        if(tx_queue_send(&ux_app_MsgQueue, &BufferCtl.state, TX_NO_WAIT) != TX_SUCCESS)
        {
          Error_Handler();
        }

      }
    }

with this change, and even with the startup file and linker filed changed to H753, I still get the audio looping, and with the BSP_AUDIO_OUT_Pause(0), I get NO audio. 

I'm not sure what to do. 

[audio]

BTW, my board is MB1246 H753 E02, I cannot find the schematic that you mentioned for me to compare to. 

Edit: You mentioned MB1246 B05 in here, I couldn't find the schematic. I work with this

[FBL]

Hi @audio 

The initial issue of this thread is clear and you confirmed as solved. If that's ok with you, please select the answer that help you to solve your initial issue of linker script.
For the follow up questions, you should start a new discussion about noise looping and I will be able to help you further.

[FBL]

Hi @audio

I have a better approach to address the echo (looping noise) issue effectively. I implemented a double-buffering approach where we clear (zero out) one half of the SAI audio buffer while writing to the other half, then swap the operation accordingly. This ensures that old audio data is removed before new data is processed, minimizing unwanted noise. It works on my end ! Add between /* USER CODE BEGIN 1 */ and /* USER CODE END1 */
in ux_device_audio_play.c

uint32_t half = AUDIO_TOTAL_BUF_SIZE/2;

void BSP_AUDIO_OUT_HalfTransfer_CallBack(uint32_t Instance)
{
    memset(&BufferCtl.buff[0], 0, AUDIO_TOTAL_BUF_SIZE/2);
}

void BSP_AUDIO_OUT_TransferComplete_CallBack(uint32_t Instance)
{
    memset(&BufferCtl.buff[AUDIO_TOTAL_BUF_SIZE/2], 0, AUDIO_TOTAL_BUF_SIZE/2);
}