This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems porting Bluetopia from MSP420F5529 to MSP430F5219 - BTPS_ERROR_HCI_INITIALIZATION_ERROR

Expert 1570 points
Other Parts Discussed in Thread: MSP430F5219, CC2564

I had some code based on the SPPLE lite example running OK on the 5529 experimenter board, with the CC2564 BT board attached.  Now I'm trying to port this to a custom target board with a MSP430F5219.  I went through the porting guidelines in the Bluetopia documentation folder, and I think I did everything needed there (with the exception that the CTS line is on P3.3 on the target and I can't change the vector to port3, but I'm not sure this is relevant).


I can program the board and run, but when it gets to BSC_Initialize (called in OpenStack), it returns -4 (BTPS_ERROR_HCI_INITIALIZATION_ERROR) after some delay.  Based on some other posts (e.g. http://e2e.ti.com/support/low_power_rf/f/660/t/248868.aspx ) it seems this is related to the UART.

One important difference is that the BT radio (CC2564) is not powered always on the new board, but my assumption is that at the point the OpenStack is called it is not starting communication with the radio.  Is that correct?  Just in case, I tried to have the radio power up before calling InitializeApplication in MainThread, but it doesn't help.

I saw another post ( http://e2e.ti.com/support/low_power_rf/f/660/p/221914/790005.aspx ) which makes me wonder if this is a PMM problem.  I know the 5219 device has a different power architecture than the 5529, so could this be an issue?

There are also some notes in the porting guidelines document regarding the clocks, but I didn't change anything here. 

Any other things I can try?

Thanks,

Angelo

  • Hi Angelo,

    The issue you are facing seems to be like a UART interface problem.

    Could you please check once again if you have done all the changes mentioned in the “Hardware Porting Guidelines.pdf” as per MSP430F5219?

    Could you please clarify on what do you mean by “One important difference is that the BT radio (CC2564) is not powered always on the new board”?

  • Hi Sundeep, thanks for your reply.  I went through the porting guide again, and checked over my changes.  I changed the pin definitions for the slow clock pin, reset (nSHUTD) pin, and RTS pin settings.  I also changed all the GPIO initialization (port directions and states) in the functions mentioned (ConfigureBoardDefaults, ConfigureLEDs, ToggleLED, SetLED).

    The UART is on the same port and pins as the original so I didn't change anything there.  The crystal on this device is also on the same pins so I didn't change StartCrystalOscillator.  Again, I'm able to program the device and even without the programmer connected the code runs and LEDs blink so I don't believe there are any crystal or general I/O issues.

    What I didn't change is the CTS pin settings.  It turns out the target board CTS is on port 3, and I wasn't able to change the CTS interrupt vector to port 3, so I left it as it was.  I'm not sure how to deal with that yet.

    Regarding the BT radio power, that chip gets it's power from a dedicated regulator which is off by default, but I'm now enabling this power before calling InitializeApplication, so I don't believe this is a problem.

    So aside from the CTS setting, I think everything is correct.  Would an incorrect CTS setting give this result?  Is it possible to set up the CTS pin on P3.3 on the 5219 device?

    Thanks,

    Angelo

  • Hi AQ,

    Yes an Incorrect CTS can give this results. as per the the hardware porting guide, it should be posible to configure to port 3 and pin 3 of your device.

    For example in file HRDWCFG.h, #define BT_UART_CTS_INT_NUM (P3IV_P3FG3)

    This should be in the form PXIV_PXIFGY where X is the Port Number (3 in this case) and Y is the Pin Number(3 in this case)

  • Thank you Sundeep, I had tried but I got errors that PORT3_VECTOR, P3IV, and P3IV_P3IFG3 are undefined.  It seems this device doesn't have interrupts on port 3.

    I'm thinking to try different protocol options when calling HCI_DRIVER_SET_COMM_INFORMATION to see if one of these allows me to disable RTS/CTS lines.  The example project had it set to cpHCILL_RTS_CTS, so maybe cpHCILL will work (or maybe even cpUART)?  I see the options listed on page 32 of the Bluetopia stack API Reference Manual, but I can't find information on the details of these different protocol options.

  • Hi AQ,

    Could you tell me what is the port you have configured you RTS On.

    and also could you please explain me how can you say that the port is 3?

  • RTS is on P3.0.  This is a custom target board which is why they are on these pins.  When I designed the board I didn't realize CTS required an interrupt.  Actually I was told I didn't need to connect CTS or RTS at all, but I think that would require changing the protocol.  I want to try changing it, except I'm really just going by trial and error on how those different protocols are implemented by the stack, and which one I should use.

  • I tried all valid protocols and none of them seem to work.  In MainThread of the original project there is the following line:

    HCI_DRIVER_SET_COMM_INFORMATION(&HCI_DriverInformation, 1, 115200, cpHCILL_RTS_CTS);
    

    When this runs, BSC_Initialize in OpenStack returns -4 (BTPS_ERROR_HCI_INITIALIZATION_ERROR).  I changed the protocol argument to all the other options and got the results below:

    cpUART - gives error -4
    cpUART_RTS_CTS - gives error -4
    cpBCSP - gives error -14 (BTPS_ERROR_HCI_DRIVER_ERROR)
    cpBCSP_Muzzled - gives error -14
    cpH4DS - gives error -14
    cpH4DS_RTS_CTS - gives error -14
    cpHCILL - gives error -4

    I hope this means that there is some other issue and that I'm not stuck because of the CTS line being on port 3.

  • I was tracing through the schematics for the experimenter board and BT evaluation module and noticed what I believe to be discrepancy, that I was hoping someone could confirm.  The HRDWCFG.h file identifies P2.1 and P2.4 as the RTS and CTS lines, respectively (or CTS and RTS from the perspective of the CC2564 device).  On the experimenter board schematic the two lines are on different headers, but on the CC256x board schematic the two lines are on the same header.  Which is correct, or am I missing something here?

  • Hi AQ,

    From the hardware porting guide what we are doing is configuring the Slow_clk, RTS, CTS, TX, RX.. lines of the CC256x to a specific pin(of a port) of host processer(in your case MSP430F5219).

    As shown in : http://processors.wiki.ti.com/index.php/CC256x_Schematic_and_Layout_Checklist#User_Interfaces

    So you should be knowing what is the port/pin number of your host processor you want to configure?

    Also from the links you have provided from the above posts(http://www.ti.com/product/CC2564). It looks like you are using CC2564B.

    So just make sure that you are using the correct service pack by Appling the patch http://processors.wiki.ti.com/index.php/CC256x_MSP430_Bluetopia_Basic_Demo_APPS#CC256XB_Information

  • Thank you Sundeep,

    Yes, I had gone through that first link with the guidelines before laying out the board and I believe I followed everything there, but it doesn't seem to mention the requirement of having the CTS line on an interrupt pin.  So, of course I do know what port/pin the lines are on, but apparently I can't configure the Bluetopia stack to match it.


    I had also gone through our last post a few times, but I somehow overlooked that note about the CC2564B patch.  That looks promising and I will try it.

    Thanks again

  • I added the CC2564B patch definition, but unfortunately this didn't help.

    Is there something I should be able to see on the hardware before the error occurs (e.g. messages on the UART, etc.) or is this error produced within the stack firmware, before there are any electrical changes I can detect outside the MCU?  I'm not able to step into BSC_Initialize so I can't tell what step is causing the problem.

  • Hello AQ,

    Could you check the status of CC256x RTS when this ocurrs please? I am trying to understand if it is an CC256x initialization issue or UART communication issue?

    Thank you,

    Miguel

  • Hi Miguel, actually I was just testing some more and I discovered that the slow clock is not being generated on my board.  I was able to read the initial message from the MCP430 on the TX line, but there were no responses, so I checked the slow clock and it is not oscillating.  But I'm not sure why.  I have this on pin P2.2 and I changed the HRDWCFG.h file to reflect this.  Any ideas what could be preventing the slow clock from working normally?

  • Hi AQ,

    Which project did you use as a template? Could you check the hal.c file? e.g. static void ConfigureBoardDefaults. Perhaps there is a conflict with a setting defined for a specific platform.

    Regards,

    Miguel

  • I used the SPPLE Lite project.  I went over the ConfigureBoardDefaults a number of times, and I have the slow clock pin set as an output, but I didn't change the P2SEL setting.  The original code doesn't use this, except for the LED outputs (to set them as GPIO).  Does the function of the slow clock output pin need to be GPIO, or a special function?  Is it driven from a timer interrupt?

  • AQ,

    The pin has to be set as a specific function, ACK. Otherwise, it would be a simple GPIO. You need to configure it such that ACK is output at this pin. Also, ACK has to be set to be sourced from the proper XTAL.

    Miguel

  • Thank you, this makes sense, but I don't see this being done in the original project.  I assumed that BT_CONFIG_SLOW_CLOCK() would be taking care of this.  In the GPIOPinTypePeripheralOutput call it looks like it sets the direction and SEL mask, so I'm not sure what else needs to be done, or if I set the clock source correctly.  I duplicated the timer1 setup code so I'm setting TA2CTL to TASSEL_1 | MC_1 | ID_0, etc. which I believe is setting the TA2CLK source to ACLK.

  • AQ,

    BT_CONFIG_SLOW_CLOCK() only defines the pin that will be used to source the ACLK to the CC256x. By default, the ACLK is set to be sourced from the XTAL1 in UCSCTL4. To enable the XTAL, please look at StartCrystalOscillator().

    For more information on the MSP430 Clock System, you may refer to the following User Guide (section 5): http://www.ti.com/lit/ug/slau208m/slau208m.pdf

    Rgds,

    Miguel

  • Miguel, sorry I'm still not getting it.  The StartCrystalOscillator code seems OK to me.  As you say the ACLK source is set to XTAL by default, and I believe the ACLK is working because I have timer interrupts driven from ACLK which are working.  I have bit 2 of P2DIR set, and I made P2SEL = BIT2, which as I understand should have the ACLK being the driven out on that pin, but I still don't see the output.

    The datasheet shows P2.2/TA2CLK/SMCLK.  Does this mean that I can only output the SMCLK on this pin, not ACLK? 

  • I made some progress.  Apparently I had some electrical problem with one board (a short on the slow clock line), so I tried another and I'm now able to see a clock on the P2.2 pin.  Initially the clock rate was 2MHz, as I assume this pin is sourced from SMCLK exclusively.  I was able to change the source of the SMCLK to XTAL by changing UCSCTL4 in SetSystemClock, and then I see the 32.787kHz clock on the slow clock line, but the stack still reports the error (-4). 

    At this point I assume the SMCLK is needed to be at 2MHz for the stack, would that be correct?

    Is it possible to drive pin 2.2 with ACLK instead of SMCLK?

  • Hi,

    1. Please check if RTS goes low after nSHUTD is high(http://processors.wiki.ti.com/index.php/CC256x_Testing_Guide#nSHUTDOWN_and_HCI_RTS).
    2. Also check the slow clock accuracy. It seems that the value you gave (32.787kHz) is out of the 32.768 +(or -)250ppm as per the data sheet.