• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 52 subscribers
  • Views 1534 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.

MSP430 crash when handling interrupt and flow control interrupt Blutopia SPP

Roy Stegers
Expert 1445 points
Other Parts Discussed in Thread: MSP430F5359

Hello!

We are working on a project that uses a MSP430F5359 and a PAN 1326B bluetooth chip, we are using Bluetopia 1.5 R2 as bluetooth stack. We have a problem when we receive a bluetooth message and at the same time a other interrupt from e.g. a sensor or push button. The MCU is handling the flow control interrupt (RTS/CTS) and then receives another interrupt (e.g. sensor is triggerd) or vise versa. This results in a MCU crash, atleast we think it's a crash since we added a life beat (a buzzer sound) that is heard every four seconds. After the "crash" the beat is not heard anymore.

Does anyone have a idea? Can we regulate the interrupts more? We think that the problem might lay here.

  • 0
    TI__Guru* 85400 points
    Moving to CC256x forum.

    Regards,
    Gigi Joseph.
  • 0
    TI__Intellectual 2360 points

    Hi Roy,

    Not sure what the issue is. A few questions:

    1. Have you enabled interrupt nesting in any ISR, i.e. have you set the GIE bit in any ISR?

    2. What does your ISR do?

    3. Does your ISR make any changes to the low power mode?

    4. Are you using one of the standard demo apps? If so can you still use the command line interface?

    5. If the answer to both question in 4 is yes, then after the lockup occurs try placing a breakpoint in HCITR_COMProcess() in HCITRANS.c and then send the GetLocalAddress command to see if the stack is still running.

    6. Have you made any changes to HCITRANS.c or HAL.c? If so what were they?

    7. Are you using IAR or CCS? Which version?

    8. Have you tried using both compilers?

    Thanks,
    Samuel

  • 0 in reply to Samuel
    Expert 1445 points
    Hi Samuel,

    1.We have checked our ISR's and GIE is not enabled in any interrupt, however in our main we enable interrupts with _enable_interrupts().

    2.Our ISR calls a function that handles device behavior, e.g. when we press a buttion some tones are played and we send communication to a other device. This is happening in the function and not in the ISR itself.

    3. No, we do not do that in our ISR's.

    4. We used the SPP demo and modified it, we removed the command inteface.

    5. Unfortionally we can not do that.

    6.No not really.

    7. We use CCS version 5.5.

    8. We cannot use IAR, it is not available to us.

    Is there anything we can try, even adding a delay in the function that handles the button behavior and disabling the buttion interrupt (and clearing the flag). has the same result, when we time this.

    Our button is on Port 1 (also 1 on port 2) our RTS and CTS are on Port 3.
  • 0 in reply to Samuel
    Expert 1445 points
    Hi Samuel,

    Yesterday we tried some things to solve the problem:
    - Disable en renable RTS and CTS interrupts in other ISR's.
    - Change MCU DCO speed.
    - Adding a delay beteween interrupts.

    All these things had no effect, do you or anyone else have any suggestions?
  • 0 in reply to Roy Stegers
    TI__Intellectual 2360 points

    Roy,

    I would try a few things:

    1. Completely remove your Buttons ISRs and your tone-playing code. See if you can reproduce the error without them.

    2. Disable entering low powers modes in IdleFunction() in Main.c. Comment out all of the code in the function.

    3. Do you have any way to trigger the device to send data? If so, after the failure place a breakpoint in HCITR_COMProcess() in HCITRANS.c, and then trigger the send event to see if the stack is still running.

    4. The interrupt-enabled CTS input pin is also on PORT1. Double check that there is no conflict between your code and the CTS code.

    5. Where does the code fail? Other than a life beat sound not being heard every 4 seconds, what event isn't happening that should be happening?

  • 0 in reply to Samuel
    Expert 1445 points

    Hi Samuel,

    Thank you for your reply! Tommorrow we will try your suggestions and get back to you.

    About suggestion 1: Do you mean remove the ISR and disabling the interrupts enterly? Our just the code in the ISR? We already tried removing all the code in the IRS and adding a _no_operation delay for a few cycles and it had the same result (we will try this again to be sure).

    About number 4: We only needed to change the pin definitions in the HDWCFG.c file right? Our is there another place we need to change? We checked our own code and we have no conflict.

    About number 5: The Bluetopia scheduler should execute it't remaining tasks and it should also send and receive data from and to the other device when needed. When the crash happens Code Composer (in the debug view) shows 0x4 and that's it. Are there any steps we can take to get more information? Not sure if we can place any break points (as your sugessted in number 3) but we will try.

    Thank you for your help so far!

  • 0 in reply to Roy Stegers
    TI__Intellectual 2360 points

    Roy,


    1. Yes, I meant remove the ISRs, disable the interrupts, and comment out the tone playing code. Completely remove your code and see if the stack fails, I want to isolate the problem and determine if the cause is somewhere in your code or perhaps not even related to your code.


    2. You only need to update the pin/register definitions in HRDWCFG.h, for RTS/CTS this would be the following definitions:

    BT_UART_FLOW_RTS_PIN_BASE
    BT_UART_FLOW_CTS_PIN_BASE
    BT_UART_CTS_IV
    BT_UART_CTS_IVR
    BT_UART_RTS_PIN
    BT_UART_RTS_PIN
    BT_UART_CTS_PIN
    BT_UART_CTS_INT_NUM

    5. The Bluetopia scheduler stops running? So neither the idle function or HCITR_COMProcess() are called after the failure? If the processor is in sleep mode it's normal for the scheduler to not run (the CPU is not running), that's why I requested to remove the code in the idle function because it puts the processor into sleep mode. The processor wakes from sleep mode when it receives the CTS interrupt. You should be able to use the CCS debugger, it works for others including myself. Try disabling all optimizations and including debug information. Optimizations can be disabled with Project / Properties / Build / MSP430 Compiler / Optimization / Optimization level / off; debug information can be included with Project / Properties / Build / MSP430 Compiler / Debug Options / Debugging model / Full symbolic debug, instructions are from CCS 6.

    Thanks,
    Samuel