• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 672 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CC2564CSTBTBLESW: Unaligned usage fault on Cortex M7 from _HCI_Read_Local_Version_Information

CC2564CSTBTBLESW: Bluetopia stack fails to open on i.MX RT1010

Benedek Kupper
Intellectual 330 points
Part Number: CC2564CSTBTBLESW
Other Parts Discussed in Thread: CC256XCQFN-EM, CC2564, CC2564C

I've previously set up an A2DP source-sink demonstration using CC2564CSTBTBLESW v4.2.1.1, CC256XCQFN-EM, CC256XEM-STADAPT and STM32F4Discovery. This is working well so far.

Now I've ported this to an i.MX RT1010 (Cortex M7), only replacing the HCI and HAL components. The HCI communication seems to be working well, as there's measured transfers in both directions, but the stack initialization returns with error (error code -4). I couldn't really map the error code to a specific component as many of them use this error code. I have recorded the TX DEBUG pin with the TI Logger application on both setups, the captured logs of both are attached. (I had to zip them as the lgr file extension isn't supported for upload.) Please help me find the root cause of the issue and some suggestions to solve it.

Bluetopia startup logs (iMXRT, STM32).zip

  • 0
    TI__Mastermind 40965 points

    Hi,

    Looking at your logs, it doesn't appear that the CC2564 has any unexpected behavior. The issue likely lies on the stack porting. I suggest you examine those HAL components again to ensure that your issue is not due to a HAL porting issue.

    An addition wrinkle may be how the CC2564 Bluetopia stack libraries are built for Cortex M4 platforms. While the Cortex M7 is supposed to be compatible with code compiled for the Cortex M4, there may still be some incompatibility. Unfortunately, as the IMX platform is not a TI device and not on the list of devices supported by the Bluetopia stack, we will be unable to help directly on porting the stack on E2E. I suggest you take a look at the FAQ for resources:

    https://processors.wiki.ti.com/index.php/CC256x_Forum_Guidelines_and_FAQs#What_about_other_MCU_support.3F

    You can also contact your local, assigned TI field support team for more information on support options.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 330 points

    The reason I have some doubts about the problem being in the HCI HAL is that the communication itself works, like you said, it doesn't appear that there's any unexpected behavior. The problem is that without access to the source code and a unique error code, I cannot make sense of what exactly goes wrong in the stack.

    This version of the Bluetopia stack has the libraries compiled for Cortex M7 as well (in all floating point configurations), I'm currently using the single precision version, so in theory this shouldn't be a problem. In reality I'd like to know if the stack has ever been successfully run on a Cortex M7 microcontroller before.

  • 0 in reply to Benedek Kupper
    TI__Mastermind 40965 points

    Hi,

    I will look into that M7 stack further and see what platform it was designed for, and whether there may be some build issue with the stack.

    Could you try linking with the Cortex M4 version of the stack and seeing if that results in different behavior? The Cortex M4 binaries should be compatible with Cortex M7 devices.

    In the meantime, I'll keep examining the logs and compare that against the stack source.

    Regards,
    Michael

  • 0 in reply to Michael Reymond
    Intellectual 330 points

    I have tried the floating point-less CM7 version, as well as building it for Cortex M4 architecture, but it didn't result in any changes.

  • 0 in reply to Benedek Kupper
    TI__Mastermind 40965 points

    Hi,

    Looking into your logs some more, it appears that there is some issue with the functionality of the HCILL module in your i.MX RT1010 application. If you look at the IMX logs, one of the last messages on the log is how the CC2564C sends a GOTO_SLEEP_IND_MSG, which is supposed to be ACKed by the host but never is done. On the STM32 logs, the STM32 sends a GOTO_SLEEP_ACK_MSG as expected.

    I suggest you try disabling HCILL first as a debug step to see if that resolves things. To do so, you can go to main() or wherever you have the HCI_DRIVER_SET_COMM_INFORMATION() macro, and instead of using cpHCILL_RTS_CTS as DriverInformation.COMMDriverInformation.Protocol, replace that with cpUART_RTS_CTS, thus disabling HCILL power save.

    If disabling HCILL works, then you should probably look at your HCITRANS.c porting file. There is a porting guide for that file in the documentation in the SDK, under HCITRANS.pdf, but you can also refer to the HCITRANS.c you use for the STM32 platform and ensure that you have implemented the needed functionality using i.MX RT1010 native components.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 330 points

    I've changed cpHCILL_RTS_CTS to cpUART_RTS_CTS, and also tried with cpUART value, but the result is still the same, Stack Init Failed: -4.

    My starting point was the hcitrans.dma version of the CC2564CSTBTBLESW, I simply replaced the ST driver calls to the NXP ones.

  • 0 in reply to Benedek Kupper
    TI__Mastermind 40965 points

    Hi,

    After you made the modifications to disable the HCILL functionality, did the firmware log output change at all? Does the stack initialization progress further, or does it still get stuck right after the controller signals to the host that it is going to sleep?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 330 points

    Here is my logs with using cpUART_RTS_CTS: iMX log cpUART_RTS_CTS.zip

  • 0 in reply to Benedek Kupper
    TI__Mastermind 40965 points

    Hi,

    Thank you for providing those firmware logs. Looking through them, it appears that despite the CC2564 no longer going to sleep, the initialization process seems to stop at roughly the same point, right after the RF PHY calibration is completed. From this, it looks to me that the HCILL/sleep functionality porting is probably not the cause.

    Did you try removing compiler optimization and seeing if that affects things?

    Also, could you perform some sanity checks on the host platform to ensure that there isn't a stack overflow or other memory corruption going on while running the stack init code?


    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 330 points

    For the record, I tried with different optimization as well, in that case I could get different results with successive runs of the same image, the stack would even return with -3 instead.

    So far I've set the HCITRANS DebugEnabled to true, to see on the console that the UART frames are sent and received correctly. This hasn't caused any side effects when it was enabled on my STM32F4Discovery setup (although in that case USB VCOM was used, and in this setup it's the regular debug UART of the iMX RT1010EVK). Now I've tried to run the stack with the DebugEnabled set to false, and it finally works! I have successfully played sine wave with the setup being the A2DP source, so I believe the stack porting was successful.

    As to how exactly the HCITRANS debug printing can influence the stack execution, I'm not sure about. The printing definitely takes up execution time, but I didn't expect the stack to be time sensitive.