Hi,
we are developing SW for a new product using the C6746 and noticed the following strange effect when using the McBSP.We use the McBSP to interface to a 4Mbit/s PCM highway (64 timeslots, 8bit/slot). Clocks and framesync are generated externally. We use Transmit Multichannel Selection Mode = 3 and Receive multichannel selection mode = 1.
If timeslot 0 is selected in RCER and not selected in XCER, the first bit after the end of the framesync is driven low (or hi depending on the data written to DXR for that timeslot) by the McBSP instead of staying Hi-Z.
Any ideas what's causing this? See screenshots of the signals and the McBSP settings below.
best regards
Wolfgang
Hi
I believe the DX pin for McBSP1 has a default IPU on it, is there something on the board, or the default IPU/IPD configuration that could be impacting this? Additional thing to check would be to see if changing the DXENA bit makes a difference.
Is this custom hardware and software? '
Regards
Mukul
Don't forget to verify answers to your forum questions by using the green "Verify Answer" button.
thanks for your answer.
There are pull-ups, but I don't think that they are impacting this. The effect of the pull-ups is that the output voltage is slowly rising after the bit has been driven low.Wether the bit is driven low or hi depends on the data written to DXR, so this is most probably not related to the pull-ups.
Currently, DXENA is set, since we have several devices connected to the same TDM bus. We will set DXENA = 0 and check wether this changes the behaviour.
Our HW is a prototype for a PBX mainboard, the TDM bus signals (CLK, FS, ...) are generated by an FPGA which implements the TDM switching.
we made some tests with DXENA = 0, the behaviour doesn't change.
Are you using 64 all channels? Is this happening only the first channel?
Regards,
Hyun
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
Check out these great resources
http://processors.wiki.ti.com/index.php/Category:C5000---------------------------------------------------------------------------------------------------------
we are using 64 timeslots, but not all of them are enabled. Take a look at the register dump in my first posting.The problem is that the first bit after the falling edge of the framesync is driven hi or lo (depending on the bit in DXR) instead of staying hi-Z. In our case that's effecting only the first timeslot, I don't know what's happening if the framesync is longer than the first timeslot.
Can you move the first slot to other time slot for a workaround?
we have a workaround for our current product, but the problem effects the processor selection for our next product.