• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 564 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.

CCS/MSP432E401Y: Debugger hangs CRC driver

Robert Macklin
Intellectual 505 points
Part Number: MSP432E401Y
Other Parts Discussed in Thread: MSP-EXP432E401Y

Tool/software: Code Composer Studio

Using Simplelink Ethernet MSP432E401Y MCU Launchpad with CCS updated to latest 9.3 version.

My application needed a CRC calculation so I used the CRC driver from the TI driver library.

I found that the call to CRC_init() hangs waiting for the peripheral to be ready when run under debug.

If I reset the board without the debugger running, my app runs fine.

I loaded the CRC example application "crc32_MSP_EXP432E401Y_nortos_ccs" to test with minimal code.  The example does not use the TI driver library, but it has similar logic in its CRCInit() function that waits for the peripheral to be ready.  This example also hangs waiting for the CRC peripheral to be ready when run under debug.

I noticed this comment in the source code for the driver:

        /* CCM hardware has a rare issue where any given power state change can cause the state to hang.
         * As a workaround, we only change the power state once, at init(), and do not power it down. */

What can be done to allow the debugger to run with an application that uses the CRC peripheral?

  • 0
    TI__Mastermind 29105 points

    Hey Robert,

    It does seem that the comment and the fact that it's hanging in init() seem to be related.  The Debugger can effect power modes as it's actively controlling the MCU.  

    My first thought is to try free running the debugger through the init and then pause and resume normal debugging.  I know it's not ideal, but let me know if that works for you.  

    I'll try and load up this example on the launchpad in the next few days and see how the debugging works for me.  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    TI__Mastermind 29105 points

    Hey Robert,

    Were you able to get this working on your side? 

    Unfortunately, due to a string of shipping delays, I've been unable to test this on my side.  Hopefully should change this week.   

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Intellectual 505 points

    Thanks for getting back to me.  I have found a few ways to trick it into working.  I can load the new code into flash, then reset the board to start my application.  Then I change the debugger settings to connect without downloading and am able to debug.  This has been enough to make progress.  I think I will write a software CRC that I can use under debug if I need to do some more intensive development.

  • 0 in reply to Robert Macklin
    TI__Mastermind 29105 points

    Hey Robert,

    Glad you found some sort of workaround for now.  I'll reach out to the TI Driver team and see if they are aware of this behavior.  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    TI__Guru* 96960 points

    Robert,

    Where are you calling CRC_init from (e.g. main(), a task, etc.)?

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 505 points

    It's called at the top of main along with the other "_Init" functions.

    int main(void)
{

    /* Call driver init functions */

    Board_init();

    GPIO_init();

    Display_init();

    UART_init();

    SPI_init();

    ADC_init();

    NVS_init();

    CRC_init();

  • 0 in reply to Robert Macklin
    TI__Guru* 96960 points

    Hi Robert,

    I cannot reproduce your issue. Can you export a small project that shows the problem? I tried in on MSP-EXP432E401Y Launchpad. What board are you using? Also, what gel file are you using? The standard one (emulation\gel\msp432e401y.gel) that comes with the target configuration supplied by the examples.

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 505 points

    Todd,

    Yes, I am using the MSP-EXP432E401Y LaunchPad board with CC 9.3.  

    I was able to produce a similar issue using the CRC example:  crc32_MSP_EXP432E401Y_nortos_ccs

    Have you tried running the example?  It doesn't use the library, but it fails in the same way.

    Rob

  • 0 in reply to Robert Macklin
    TI__Guru* 96960 points

    Robert,

    I just tried that one and it worked fine for me. I stepped through all the code in main with the debugger. I let it run after a power-cycle. Both ways seem to work fine. What do you mean by hang? Does the target go into the weeds or is it looping on something?

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 505 points

    I've installed CCS 9.3 on my home computer now and have the same problem.  The code hangs in the endless loop waiting for peripheral ready:

        while (!SysCtlPeripheralReady(SYSCTL_PERIPH_CCM0))
    { }

    Both my code and the CRC example hang the same way.  I am using the same development board on both setups, I do not have a second board to test.

    I also tried upgrading to CCS 10, but was unable to build code without strange gmake errors, so I went back to CCS 9.3.

    At this point I have written a software CRC routine that compiles in when DEBUG is set.

**Attention** This is a public forum