STM32F446 does not receive SPDIF data

[HMüll.4]

Hi,

I'm trying to use a STM32F446 to receive some SPDIF-data. There are no complicated things to be done with the received data, just a few simple calculations. Unfortunately I do not receive anything at the moment.

I have configured the SPDIF-interface within STM32CubeMX: Selected input is IN0, the input does not wait for activity, the manximum number of retries was set to 63, and.the preamble bits are not copied. Everything else was left to default.

Clock configuration was done in a way where the core (SYSCLK) is at 180 Mhz, SPDIFRX also gets 180 MHz. Hope this is correct as I'm somewhat unsure about this part.

Within the generated code I have replaced HAL_SPDIFRX_RxCpltCallback(), it now is an own function in my code.

Nevertheless, when I'm running this stuff, I do not receive anything, none if the different callback functions is called. The pin PB7 receives a valid SPDIF-signal, this was verified with an oscilloscope (however, it runs with a somewhat unusual frequency of 100 kHz).

So what could be missing here? The pin-mapping of PB7? Shouldn't this be done by the CubeMX configuration already?

Any ideas how to track down the problem?

Thanks!

PS: one strange thing I noted: when I set the code-generation option "Set all free pins as analog", the generated HAL-code crashes when configuring GPIO13. When I manually remove all GPIOs starting at 13 or disable this option, initialisation works well. Not sure if this can be related somehow...

[Simon V.]

Hello,

Maybe you could start with the polling function in stm32f4xx_hal_spdifrx.c HAL_SPDIFRX_ReceiveDataFlow() or HAL_SPDIFRX_ReceiveControlFlow().

Regarding PB7: you can configure it as a simple digital input + interrupt to verify that the signal is correctly detected by the input circuitry.

For your information, an spdif example is present in HAL STM32F7 eval.

Regards,

Simon

[waclawek.jan]

Read out and check/post SPDIFRX and relevant GPIO registers content.

> PS: one strange thing I noted: when I set the code-generation option "Set all free pins as analog", the generated HAL-code crashes when configuring GPIO13.

What is GPIO13?

And what is strange in this? Whatever you've clicked, it's your code now, so debug as usually.

JW

PS. Remember what I've told you:

Alternatively, if you prefer this path, just click everything in CubeMX, and it then either works or not.

And you've got the "or not" leg. That's how clicking works.

[HMüll.4]

It is strange because generated code, that was not modified in any way should work and not crash. So no reason to blame me for asking questions here, when you do not understand WHAT I'm asking!

[waclawek.jan]

> It is strange because generated code, that was not modified in any way should work and not crash.

Yes, in the ideal world. However, Cube/CubeMX is an incredibly huge undertaking, and as such, it inevitably has flaws, even with its limited scope. I don't say bugs - although there certainly are such - but mostly it's the unexpected interaction between various elements of it.

This is also why we call for simple and clear examples (which represent a huge undertaking, too, so that would compete with Cube for resources within ST), but ST squarely refuses to go that way.

> So no reason to blame me for asking questions here

Sorry if this sounded like I blame you for the question. No, questions are of course what moves things forward here. I just pointed out that you should expect problems, and that you should do some basic troubleshooting for yourself, for your own benefit. For example, "crash" is not a very helpful description of the problem - does it go into some infinite loop, or does it go into the (hard)fault handler, or what else are the symptoms? etc.

But you've marked the thread as solved, so, please tell us, for the benefit of all readers, what was the problem and how did you solve it.

JW

[HMüll.4]

OK, still no success.

When I change PB7 to work as GPIO Input and poll it with HAL_GPIO_ReadPin(GPIOB,7), I never see a result GPIO_PIN_SET. So the situation seems to be the same, the 3.3V signal is not detected.

The signal definitely is there, I can measure it at pin 59 of the MCU.

The pollign code from the HAL STM32F7 eval looks very similar to mine, so I can't see a difference here.

Where I'm still unsure: my clock settings. I just played around with them in STM32CubeMX until I got a core clock of 180 MHz (same clock for the SPDIF subsystem). Can a wrong clock configuration prevent the input from working properly?

[waclawek.jan]

> When I change PB7 to work as GPIO Input and poll it with HAL_GPIO_ReadPin(GPIOB,7), I never see a result GPIO_PIN_SET.

You are not suppsed to use HAL_GPIO_ReadPin() with pin number as parameter, you have to use GPIO_PIN_x symbol. And that is not the pin number:

#defineGPIO_PIN_7 ((uint16_t)0x0080) /* Pin 7 selected */

Generally, whenever in doubt, in debugger or using any other method, read out and check/post GPIO registers content.

JW

[HMüll.4]

> #defineGPIO_PIN_7 ((uint16_t)0x0080) /* Pin 7 selected */

OK, this works, I can see the input toggling between GPIO_PIN_RESET and GPIO_PIN_SET. This is true for both, a manually applied LOW/HIGH signal as well as the SPDIF-signal I want to receive.

Now when I change the configuration of PB7 to SPDIFRX_IN0 (while leaving everythign else in CubeMX unchanged) and add the following into my main loop:

   HAL_StatusTypeDef ret=HAL_SPDIFRX_ReceiveDataFlow(&hspdif,spdifData,4,100);

ret always returns HAL_TIMEOUT which is caused by

      /* Wait until RXNE flag is set */
      if (SPDIFRX_WaitOnFlagUntilTimeout(hspdif, SPDIFRX_FLAG_RXNE, RESET, Timeout, tickstart) != HAL_OK)
      {
        return HAL_TIMEOUT;
      }

   which itself runs into this timeout because

__HAL_SPDIFRX_GET_FLAG(hspdif, Flag) == Status

always is true. So for me this looks like there never a reception of valid data is detected?

[HMüll.4]

Next test: I tried to invert the input signal to avoid there is a problem with the logic of it. But same result, nothing is received.

May be there is a problem with the structure of my incoming SPDIF-signal? It has a frequency of 100 kHz (means 100000 stereo-frames per second are sent) and contains 20 bit of payload.

The upper four bits (Auxiliary) are set to 0100, validity-flag is 1, user- and channel-status-bit are 0 and even parity is used.

[waclawek.jan]

Read out and check/post SPDIFRX and relevant RCC and GPIO registers content.

JW