• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 677 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Initialization fault of the Bluetopia SDK with the PAN1323ETU and the EK-TM4C1294XL development board using a TM4C1294NCPDT

Software Engineer
Prodigy 40 points
Other Parts Discussed in Thread: EK-TM4C1294XL, TM4C1294NCPDT

Hello,

We are using the EK-TM4C1294XL development board with the TM4C1294ncpdt processor  and the PAN1323ETU board to connect to another device using Bluetooth LE via the Bluetopia SDK.  We are running into an issue with the call to BSC_Initialize(), where the FaultISR is being called after a few seconds.

We can breakpoint on the execution of HCITR_COMOpen and HCITR_COMWrite, and both seem to execute normally.  However, when we break on the execution of HCITR_COMClose, we are receiving an HCITransportID which is invalid (~168,821 instead of the expected '1', and the received value changes every execution).  After this function is called, we enter the FaultISR.

We have also tried using the __SUPPORT_CC256XB_PATCH__ flag, as I am unsure if it is using the CC256x or the CC256xB part, but having or not having that flag does not change the operation.

We are using CCS v6.0.1 and Bluetopia's M4 v1.2 stack.

Thank you,

- Glenn

  • 0
    TI__Mastermind 32615 points

    Hi,

    PAN1323ETU is CC256x device and you will not require __SUPPORT_CC256XB_PATCH__.

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

    Make sure that your hardware porting is fine.

    Can you provide the terminal logs? 

  • 0 in reply to Sundeep Javvaji
    Prodigy 40 points

    Thank you for your response.

    Unfortunately, we don't have the terminal logs set up to be sent anywhere, so I cannot provide them for you.

    We were seeing the nSHUTD line go high, and the bluetooth module responded by pulling its RTS line low.

    We have looked at the UART lines between the development board and the bluetooth board, and we do have some data transferring between them.

    The microcontroller sends the following string: 0x01 0x03 0x0c 0x20  (which I believe to be a reset command).

    The bluetooth module responds with the following string: 0x00 0x2e 0x8d 0x04 0xc4 0x00  (which I believe to be a response to the reset command of a success).

    However, no more communication between the modules occurs.

    Thanks,

    -Glenn

  • 0 in reply to Software Engineer
    Prodigy 40 points

    Hello

    We have placed a breakpoint in the RxInterrupt in Bluetopia's HCITRANS.c, and can see the UART data in my previous post being received by the microprocessor. While on the breakpoint in RxInterrupt, we placed a breakpoint on TxInterrupt, which did not execute again before the FaultISR executed.

    After breaking on RxInterrupt, I added breakpoints to HCITR_COMClose() and HCITR_COMOpen(). The call to HCITR_COMClose() occurred with HCITransportID == 177047. The FaultISR then executed.

    We placed a breakpoint in HCITR_COMProcess, and the function did not execute before the FaultISR occurred, even though the packet was received in the RxInterrupt.

    We also enabled the UART output for the terminal, and received only the text "OpenStack().". I am assuming that this is the terminal log that you were requesting.

    Thanks,

    -Glenn

  • 0 in reply to Software Engineer
    Mastermind 7225 points

    Hi,

    You mentioned,

    “The bluetooth module responds with the following string: 0x00 0x2e 0x8d 0x04 0xc4 0x00  (which I believe to be a response to the reset command of a success).”

    That sequence of bytes is not a valid HCI event. HCI Events start with a 0x04, followed by the event type, event length, and payload. In this case the radio should respond to an HCI Reset with a Command Complete, which would look like the following:

    0x04 0x0E 0x03 0x01 0x03 0x0C 0x00

    Regards,

    Stonestreet One.

  • 0 in reply to Stonestreet One Support
    Prodigy 40 points

    It looks like we tried to post at the same time:)

    Thanks to a phone call with a TI FAE, we were able to find our issue. The problem was our stack size which was too small. The default stack size was 512 bytes and the issue was fixed when that was increased to 2048. Another pitfall we had was that the inclusion of __SUPPORT_LOW_ENERGY__ was missing from the predefined symbols list in the Advanced ARM Compiler Options.

    Jim (another company employee)