BSC_Initialize returns -4

Hi,

How about the nSHUTDOWN? Is it going high.

Please see the first three steps from http://processors.wiki.ti.com/index.php/CC256x_Testing_Guide

also see http://processors.wiki.ti.com/index.php/CC256x_Schematic_and_Layout_Checklist

Sundeep

We believe that the first two steps are functioning correctly

• We see RTS come up with the FLOW_ON command in HCITR_COMOpen after the BT_DEVICE_UNRESET() is called.
• HAL_CommConfigure is called from HCITR_COMOpen.  It sets the baud rate as 115200 and passes in the flags of (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE).  I don't see where the Hardware Flow Control gets set however

We then get to the rub.  We can see TX send over what looks like 3 bytes (one at a time if we are stepping through the function) then RX sends something back.  At this point all communication stops.  If we jump to the conclusion of BSC_Initialize we find that it has returned -4 and the the nSHUTDOWN line is low, indicating that the chip has turned off.

We setup the ACLK to run off XT1 at 32,768 Hz.  We setup the A1 Timer as follows

TIMER_A_configureUpMode(
              TIMER_A1_BASE,
              TIMER_A_CLOCKSOURCE_ACLK,
              TIMER_A_CLOCKSOURCE_DIVIDER_1,
              33,
              TIMER_A_TAIE_INTERRUPT_DISABLE,
              TIMER_A_CAPTURECOMPARE_INTERRUPT_ENABLE,
              TIMER_A_DO_CLEAR
);

We use this to drive a millisecond tick counter that we provide in the Tick Counter Call Back.

Hi,

Error -4 is defined as BTPS_ERROR_HCI_INITIALIZATION_ERROR, which means that your uart is not configured correctly.

You are saying that the nSHUTDOWN is low? this pin should be high before the RTS goes low.

Mind that the accuracy of the slow clock frequency must be 32.768 kHz ±250 ppm for Bluetooth use.

As the soft ware is working with he 5529 EXP board. I don't think you need to change any thing in the software for your board. If you are trying to use different pins for UART then this is all you need to change in the SW as mentioned in the hardware porting guide.pdf, which is part of the documentation folder of the SDK.

Hi Sundeep

nSHUTDOWN starts low, when we hit BT_DEVICE_UNRESET() in HCITR_COMOpen(), nSHUTDOWN goes high.  After this, HCI_RTS does go low.  It remains high until we finish BSC_Initialize() at which point -4 is returned and nSHUTDOWN goes low.

We us XT1 to generate the 32.768 kHz for the Bluetooth.  XT1 is an oscillator, not a crystal.  We feed this through a level translator into the CC2564 chip.  It goes into the MSP430 chip on P5.4 and we use it for the ACLK as described in the last post.

We still receive one burst of data on the TX and RX line (on the MSP430 Side).  

We originally used some different pins and modified HRDWCFG.h to match this.  We've since changed our pins around to be an exact copy of the SPPLEDemo_Lite:  nSHUTDOWN P7.5, RTS P2.1, CTS P2.4, TX 4.4, RX 4.5.  The Slow Clock is still on P1.0, but that line is not brought to the CC2564 chip since we are bringing in the Slow Clock directly from the XT1 oscillator.

Hi,

I hope the command that is sent could be HCI_Read_Local_Version_Information.

Can you get me the data what is been received? 

Sundeep

We transmit 0x1, 0x3, 0xC, 0x0.

The byte that is read back is 0x0.  However, the scope shows that data is being sent that is clearly not zero and clearly longer then one byte.  The first byte attempting to be returned is 0x4.  The problem looks to be the rate of transmission.

• On the Experiment Board, the each bit (either RX or TX) is 8 micro seconds long.  
• On our board, a TX bit is 24 micro seconds while a RX bit is 12 micro seconds.  

What could cause this difference in rate?  I'm assuming this difference is what causes the communication to fail and the BSC_Initialize to return -4.

From the USB side of the code (which is where we started our project), we set up our clocks as follows (mclkFreq is 8,000,000).  Is there something off in here?