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/TMS320F28069: Program Stops after a certain duration in Debug mode

Part Number: TMS320F28069


Tool/software: Code Composer Studio

Hi

  We are using our 28069 board ( whose schematic is a referenced from 28069 launchpad) for a GSM application. 

A GSM module (Fibocom G610) is connected to the UART (SCIB). Apart from this CAN, PWM and ADC peripherals were used.

Before Starting the GSM interface all the applications were working fine.

After including the GSM function for sending the AT commands, the program stops after a certain duration ( sometime immediately, sometime say after 10 minute)

Program stops in the sense, no variables gets updated in the watch window. Even the variables that gets updated in the ADC ISR as well.. which signals that CPU is halted by itself..

What could be the possible reason for program stopping by itself  in the middle?

When the same code is run in the standalone mode... After stopping the program restarts multiple times after each stop !!

KIndly let us know the possible reasons for these issues ....

Thanks

Lenin.

  • Hi Lenin,

    Do you know where your code is when the issue happens? It sounds like there it might have taken an illegal interrupt, which usually means an invalid opcode was fetched. If so, there could be many reasons: array overflow, stack corrupution,...many others. In you GSM build are you enabling interrupts which are inactive in the debug scenario?

    I didn't really follow "When the same code is run in the standalone mode... After stopping the program restarts multiple times after each stop !!". Does this mean it's operating fine without the GSM module attached?

    If so, please look at the SCI pins and at the power supply voltages to be sure everything is within specified limits. Sometimes a voltage glitch can throw the PC and cause something like what you've seen.

    Regards,

    Richard
  • Hi Richard

      Thanks for the response.

    Do you know where your code is when the issue happens?

    As of now we have removed all other functions and in the while(1) loop there is only one function, that is the send_AT() function. Apart from this an ADC interrupt happens @ 0.2 ms. I doubt the code stops when it executes the following function . Is there a way to find out the Program Counter location when it stops ?

    void scib_xmit(int a)
    {
    while (ScibRegs.SCIFFTX.bit.TXFFST != 0) {
    if( CAN_TimerTimeout>500) // corresponds to 100 ms
    {
    SCI_Transmission_Stuck =1;
    break;
    }
    else
    SCI_Transmission_Stuck =0;

    }
    ScibRegs.SCITXBUF=a;

    }

    It sounds like there it might have taken an illegal interrupt, which usually means an invalid opcode was fetched. If so, there could be many reasons: array overflow, stack corrupution,...many others. In you GSM build are you enabling interrupts which are inactive in the debug scenario?

         Actually the SCI TX and RX interrupts are enabled, though we are not using that. However we disabled those interrupts and checked, but still the issue remains.

    I didn't really follow "When the same code is run in the standalone mode... After stopping the program restarts multiple times after each stop !!".

    I mean the standalone mode of 28069 ( just powering up the launchpad with 5 V). We connected a bluetooth to another UART SCIA and sent some messages (in the begining of the code as well as within the send_AT () function) to check where the code stops.  The intended messages were received for some time in the bluetooth after that suddenly it stops and once again the start message appears again and again.

    .

    .

    .

    msg = "\r\n\n\n Program Starts \n\0";
    scib_msg(msg);

    IER |= M_INT1; // Enable CPU Interrupt 1

    //--- Enable interrupts
    SetDBGIER(IER); // Configure the DBGIER for realtime debug
    asm(" CLRC INTM, DBGM"); // Enable global interrupts and realtime debug


    while(1) 

    {
    // count1++;
    sendAT();

    }

    Does this mean it's operating fine without the GSM module attached?

      Actually the program continues to run without any issue if the GSM module is removed. It even works if the GSM is replaced with a bluetooth HC-05. Whatever commands being sent is getting printed in the bluetooth terminal..

    Thanks

    Lenin.

  • Hi Lenin,

    Are you are able to get an emulator connection to it when it's running out of flash? If so, you should be able to halt the debugger when the issue happens and look at the disassembly window to see where the PC is.

    Did you check the SCI signals and power supply voltages on the device with the GSM module connected? The random nature of the failure, and the fact that is only happens with one type of module, does seem to imply a hardware origin.

    Regards,

    Richard

  • Hi Richard

      Yes, it turned out to be an hardware issue. Actually we powered the GSM module also from the 5V pin of the  launchpad ( which is powered from the USB port limited to a 500 mA).   However the GSM module itself consumes around 450 mA as per its spec. So that seems to be the issue.

      After providing a separate power source for the GSM, the code works fine.

    Thanks

    Lenin.

  • Hi Lenin,

    Glad to know you found the issue, and thanks for letting us know.

    Regards,

    Richard