• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 890 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.

Program execution stops seemingly randomly

3446793
Intellectual 790 points
Other Parts Discussed in Thread: TMS320F2812

Hello,

I am programming the digital signal controller TMS320F2812. With the current project, an issue occurs that I have never had with similar source codes and settings. The program execution stops seemingly randomly. I first noticed this with the line

    for (i=0;i<2500;i++) asm(" RPT #255 || NOP");    // required 5 ms delay (5.1 ms)

that is reached when a breakpoint is set there. The next line however is not reached; apparently the program gets stuck with the above line. Strangely, I have used this command in many other projects and it always worked.

A few things I have looked at to track down the problem:

With the optimization level set to 0 (instead of disabled), the above line is executed, but the program gets stuck somewhere later. I cannot find the command that does not work because a breakpoint cannot be set in the region where the execution stops, but it is most likely where there are many variable declarations.

This made me suspect that the watchdog might have to do with it. It is disabled at the beginning of the code via
EALLOW; SysCtrlRegs.WDCR=0x0068; EDIS;
Checking the value in this register before the program gets stuck, however, I found that it is 0x40. Checking back, it seems to be the case for all other programs that I have written that the watchdog control register is 0x40 and not 0x68 to which it is set. I had never noticed this and never had any problems with it either.

Also, when I change the order of the source code such that all the variable declarations are before the line
for (i=0;i<2500;i++) asm(" RPT #255 || NOP");
the program still gets stuck at this point.

Overall, it is unclear to me why the program stops. What happens in my program before an infinite loop starts are mainly configurations of peripherals and variable declarations and definitions. Many other projects with the same structure, ADC setup (in which the above line is used) and project settings have worked. What could be the problem here?

Regards,

Adrian

  • 0
    TI__Guru 60865 points

    When writing to the watchdog control register, you need to include a write of 101 (binary) to bits 5:3.  If this condition is not met, then the watchdog will immediately initiate a reset (this is to protect against spurious writes).  However, these bits always read back as 0.  This is why you write 0x68 to the register to disable the WD -> it breaks down to a write of 1 to the disable bit plus the 101 key value, but when you read back you get 0x40 because the key bits read back as 0s.

    What exactly happens when the execution stops?  Do you see XRSn go low on an oscilloscope (this would indicated a watchdog trip)?

    If the debugger is connected, where does execution stop?  Is it in undefined memory location? If so, this could indicate than an ISR occurred, but that the service routine may not have been correctly mapped.  A CPU timer or PWM (or some other peripheral) triggering an undefined interrupt could cause the program to stop unpredictably.

    Can you confirm that the watchdog control register reads back as 0x40 immediately before the loop starts?   

  • 0 in reply to Devin Cottier
    Intellectual 790 points

    Thank you for your suggestions. It looks like the watchdog is indeed not the cause of the failure. WDCR=0x40 all the time as far as I can see and XRSn remains high.

    What exactly happens: The program reaches the breakpoint that is set at the line with the loop. I click on Resume. The breakpoint set at the next line should be reached and be highlighted in green. This does not happen. The line with the loop remains highlighted in light blue color, the Resume button is inactive and the Suspend button is active instead. When I click it, the loop is highlighted in green again, I can click on Resume, Suspend and keep going like this. It always stays with the same line.

    Devin Cottier said:

    If the debugger is connected, where does execution stop?  Is it in undefined memory location? If so, this could indicate than an ISR occurred [...]

    I don't understand the questions - could you please elaborate a bit?
    I tried including DINT; and IER = 0x0000; close to the beginning of the source code so that interrupts should not occur. Nothing changed.

  • 0 in reply to 3446793
    TI__Guru 60865 points

    Is it possible the pll is not locked?  If so, you may not notice much difference running through the initializations, but when you hit the delay loop it might take a really long time to execute.  You can look at the variable i in the watch window to see if it is increasing between runs or you could enable XCLKOUT and check the clock on a oscilloscope. 

    You can also look at the assembly instructions that are actually generated by looking at the disassembly window.  You can try assembly single stepping from this point to see what is happening.  

  • 0 in reply to Devin Cottier
    Intellectual 790 points

    While playing around trying your tips, I created a new project and copied the source code in there. The problem disappeared.

    I found that with the new project, the signal XCLKOUT has a frequency of 37.5 MHz (as it should), but with the previous one it was only 3.75 MHz. It is mysterious to me why there is a difference. It must have to do with some setting in the project properties, although I do not recall changing anything there.

    Thank you for providing assistance, Devin!