SPDIFRX_FRAME_SYNC not working/configured?

[BKies.1]

Hi all,

when trying to use the SPDIFRX_FRAME_SYNC on a STM32H743 I ran into a problem.

I configure TIM17 as Input capture and set TIM17_TISEL = 1 which should select the SPDIFRX_FRAME_SYNC signal, but the CCR1 register is not updated with the current counter value, when the rising edge of the SPDIFRX_FRAME_SYNC signal would occur.

Looks to me, that it is like the SPDIFRX_FRAME_SYNC signal is not there/toggling.

I could not find a possibility to put the SPDIFRX_FRAME_SYNC signal on a pin to verify it with a scope.

Additionally, my timer seems to be working, bc. when I set TIM17_TISEL to MCO1 (which is configured appropriately), the expected behaviour happens: CCR1 of TIM17 is updated regularly.

Also I presume that the SPDIFRX peripheral is configured corretly, since I can receive valid data by DMA and interrupt. So I think that the SPDIFX component should be synchonized and a valid SPDIFRX_FRAME_SYNC signal should be available.

Looking forward to any pointers and tips.

• Berni

[waclawek.jan]

This is a user-driven forum, with only casual ST presence, so it's unlikely you will get a relevant answer here.

Please ask directly ST, through the web support form or through a FAE.

Please come back with any results.

Thanks,

JW

[BKies.1]

Will do.

[Moreno1]

As it seems on newer revs of the STM32H series, the SPDIF_FRAME_SYNC is routed to TIM12, not TIM17. Refer to AN5312 for more details. I'm still trying to figure out how to handle this in my code.

[waclawek.jan]

> I'm still trying to figure out how to handle this in my code.

Well, this obviously depends on what do you want to accomplish. You can for example use it through an interrupt to detect SPDIF cable insertion.

Anyway, thanks for coming here with this info.

The spdifrx_frame_sync signal disappeared from TIM17_TISEL and appeared in TIM12_TISEL between rev.6 and rev7 of RM0433. IMO this is not correct; RM0433 ought to cover both revisions. Also, rev.7 still contains the TIM17 in the Interconnect chapter, both in Table 90. Peripherals interconnect matrix (D2 domain) and Table 92. Peripherals interconnect matrix details. There's also a discrepancy between the indicated connection, noted as S in Table 90 and as A in table 92.

@Imen DAHMEN​ , can this please be chalked up for correction?

Thanks,

JW

[Imen.D]

Hi @Community member​ ,

Thank you for reporting these errors and for helping us improve our documentation.

I will report this to the team in charge for correction.

Imen

[waclawek.jan]

Thanks, Imen.

JW

[Moreno1]

> Well, this obviously depends on what do you want to accomplish. You can for example use it through an interrupt to detect SPDIF cable insertion.

I meant handling different silicon revs with the same base timer code as you cannot guarantee what the manufacturer will eventually solder to you board.

Unfortunately however, I have to disagree with your proposal of checking SPDIF cable insertion using this method. As far as my testing went, TIM17 or 12 does detect any input on the input capture unless you start reception of data or control frames. The HAL has the sync routine embedded in those calls to make sure the receiver is sync'ed to a signal before data reception can start.

There are a few problems with the HAL approach:

1. The HAL sync process is not separate from the reception routines, meaning you cannot decouple it and start reception once you know you got a signal;
2. The sync code is duplicated on CTRL and DATA routines;
3. The sync code uses busy wait with an arbitarily long count number and no yield with HAL_Wait, which effectively hijacks your system's resources if a cable is not plugged in;

In my system I had another weird effect: Turning on Data and TIM17 works fine, I can even calculate the sample rate (I'm not really satisfied with 48kHz being displayed as 47.8kHz, but yeah, I can live with that). However, if I also turn on the Ctrl reception to have the complete stream of SPDIF, there is a bug somewhere and nothing happens - no interrupt from either Data or Ctrl, and TIM17 keeps rapidly changing its input source and no count. I have already opened a support request to deal with it, and ST is looking into it. However with the current HAL implementation I'm losing hope.

With the current HAL implementation, unless I'm using a beta or outdated version, it is not really straightforward how to go about with SPDIFRX. A very clear use case for many people using this port is to forward the port to I2S or SAI port in I2S mode, which requires some serious sync work. If ST could provide code or even a procedure for a programmer to implement this, it would be very very useful.

[waclawek.jan]

>>> I'm still trying to figure out how to handle this in my code.

>> Well, this obviously depends on what do you want to accomplish. [...]

 > I meant handling different silicon revs with the same base timer code as you cannot guarantee what the manufacturer will eventually solder to you board.

Ah, sorry for the confusion.

I don't use Cube.

JW