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.

CC2564MODA: Bluetopia "Stack Init Failed: -4."

Part Number: CC2564MODA

Hi - I am trying to get the SPPDemo going on STM32F4's using NoOs. I have just connected up the boards at each end  for the first time to today & I'm running the same SPPDemo app at each end, modified only enough to allow for different ConsoleUart pins.

Both boards report:

OpenStack().

Stack Init Failed: -4.
Unable to open the stack.

So at least they are both running (;-))

The led in the loop beyond the MainThread() call starts flashing:

/* MainThread should run continously, if it exits an error occured. */
while(1)
{
ToggleLED(NULL); // Orange Led LD3 on Disc1 @ ~2Hz

BTPS_Delay(100);
}

So the MainThread has obviously exited.

I have set the jumpers as per SWRU417, appropriate to whether the Adaptor PCB's are on the Discovery board or Eval board, and made sure that I have the right module (XQFNEM or MODNEM) at the right end.

There is some mention of the Slow Clock in other earlier threads, but nothing about what to do with it in SWRU417.

Is there anything else that I might have not done? Needless to say, I was in a hurry to see it fire up & I haven't read the manual exhaustively yet!

  • BSC_Initialize is returning -4

    From e2e.ti.com/.../341803

    Error -4 is defined as BTPS_ERROR_HCI_INITIALIZATION_ERROR, which means that your uart is not configured correctly.
    Sundeep Javvaji queries
    the accuracy of the slow clock frequency?

    Ok, so that was for someone who had designed their own PCB. Here, this is happening with the eval boards, so the hardware shouldn't be a problem.

    Can somebody from TI suggest what I might have done wrong, pelease?
  • I’ve found the problem – I had to move the 4 zero ohm links
    on the CC256XEM_STAdapt PCB's – they don’t work OOTB as configured. Don’t understand why they are configured that way - its contrary to the way that SWRU416 says that they should be set by default (see Figure 1)
  • Not quite there - the fix works on the STM EVAL board, but not on the Discovery board. Do I have to remap the Uart to the cc256x when the code runs on there?
  • Ken,

    As you know I'm working with you offline on this, but here are some resources regarding support for MCUs other than the STM320F4EVAL and our other TI supported MCUs

    processors.wiki.ti.com/.../CC256x_Forum_Guidelines_and_FAQs
  • The answer lay in C:\TI\Connectivity\CC256X BT\CC256x STM32 Bluetopia SDK\v4.0.2.2\NoOS\Documentation, in Enable_STM32_Discovery.pdfm which exploains how to adapt the SPPDEMO to run on the Disco board, by changing the Console Uart to different pins from those when running on the Eval board. This isn't mentioned in SWRU416, which is solely about the HCI Transport Uart, so beware. Also the HCI transport Uart doesn't have DMA on the more basic F4 on the Disco board.

    In the end, I couldn't get my Disco board to go, so I'm going to get a 2nd Eval board.