Hi all,

as this has been a quite weird bug so far, and Sylvain now seems to have run into some related problems when trying to make a SDCCH8 on TS1 work, I'll elaborate a bit more on it.

Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as follows:

1) The time between the TDMA interrupt happening and starting to execute l1_sync() and actually being able to configure the TPU window and tell the DSP what to do was too short for performing the scheduled work in the very same TDMA frame.

2) As a result, the actions that we thought were performed in the same TDMA were actually performed one TDMA later. Somehow we must have had another off-by-one error and thus the two errors compensated themselves in most cases, particularly for Rx

3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after which the DSP has to do the FEC, Fire CRC, burst spreading, etc - before being able to generate the bits for the furst burst. Those bits then get sent over the TSP to the ABB (into its burst buffer), from where they are sent based on TPU signals.

So what happened is that the data of the first burst was not in the burst buffer yet, and the TPU signals triggered sending the last burst of the previous MAC block, rather than the first burst of the current.

This is why Dieter added the

  tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */

to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one TDMA frame. At that time, the DSP has by long finished writing the new burst bits in to the ABB burst buffer, and we can transmit the correct burst data.

I personally believe it would be better to simply move the TDMA interrupt a bit more ahead. Rather than occurring immediately before TS0, we could set SYNCHRO in a way that it occurs at a defined point in time still quite a bit into TS7.

In this case we hopefully have enough time for the DSP to be able to transmit in TS0, making the timing sequence easier to understand.

Hope that helps to explain...