F28335 XINTF Effected by Counter Two Divider

Chris Harthan

Part number: TMS320F28335PGFA

Hello All,

We have found an inexplicable correlation between writing a value to the divisor register of timer two and the reliability of writes to the XINTF at address 0x4211. Our system has a state machine mapped into the 0x42XX area of the XINTF. This is an interface to a number of A/D converters. Our technicians reported occasional lockups during calibrations of the devices. This is an automated, overnight procedure. When a device locks up, a day is lost.

The state machine locks up because it is waiting for a ready status from an A/D that is not present in this version of our device. It happens during the start of the acquisition, suggesting that the state machine was not being reset properly.

In order to keep the technicians progressing we added a software retry feature, which will restart the state machine if the calibration cycle does not finish in 28 seconds. To do this, we used timer two. What we found is that the retry never occurred. Further investigation revealed that if 28000 is written into the divider register at any time, whether we actually use timer two, or not, the problem appears to go away.

This is a very repeatable phenomenon. A number of units have displayed exactly the same behavior. If we do not write to the divisor we can induce a failure on the bench within 2 to 26 hours, starting a cal cycle every 20 seconds. If we write 28000 to the divisor during the boot of our device, we cannot induce a failure in a 72 hour test.

Here is a snippet of code...

Void main() {
    :
    :
    :
    StartMsTimer(28000L);    // Function called at application start up, running out of RAM
    :

    // Background loop
    while () {

    } // End background while
} // End main

// Function definition
void StartMsTimer(unsigned long lTimeOut) {
unsigned long ticks;

    ticks = lTimeOut * 150L;
    *(volatile short *)0x0c13 = (ticks >> 16) & 0xffff; // hi
    *(volatile short *)0x0c12 = ticks & 0xffff;            // lo
}

We are having trouble understanding the relationship between timer two and the external interface.

Thanks.

over 9 years ago

0 Vivek Singh over 9 years ago

TI__Guru** 109105 points

Hi Chris,

Please have a look at the following errata item related to XINTF operation in errata doc "http://www.ti.com/lit/pdf/sprz272".

"Advisory Memory: Possible Incorrect Operation of XINTF Module After Power Up"

Regards,

Vivek Singh

0 Chris Harthan over 9 years ago in reply to Vivek Singh

Prodigy 180 points

Hello Vivek,

Thank you for your reply.

We looked into the XINTF issue that you referenced. "Memory: Possible Incorrect Operation of XINTF Module After Power Up"

We implemented a WDRESET command that uses the watchdog to reset the chip, and it did not have an effect on our issue.

One of the first uses of the XINTF during our boot is a parallel programming of an FPGA. This has CRC, so we would be aware of failures. Our techs have not reported any issues with this. If we are having XINTF issues immediately upon power-up, they are extremely rare.

Our design has a power supervisor that holds XRS low until the 1.9V and 3.3V have been in compliance for 200ms.

Is is still advisable to issue a watchdog reset?

Thank You,

Chris

0 Vivek Singh over 9 years ago in reply to Chris Harthan

TI__Guru** 109105 points

Hi Chris,

We strongly recommend users to implement the work around mentioned in errata for correct operation of XINTF module.

But look like even after issuing the WDRESET, you are still facing the same issue. Is that correct?

Also on below,

Further investigation revealed that if 28000 is written into the divider register at any time, whether we actually use timer two, or not, the problem appears to go away.

The address you are writing into the function are 0xC12/0xC13 which are period registers not divisor. Right? Also when you say timer two is not used. does it mean, TIMER interrupt is not enabled or timer has been stopped from running ? Is there any specific reason for choosing 28ms (28000 value) in this case? Did you try using other timer as well?

Regards,

Vivek Singh

0 Chris Harthan over 9 years ago in reply to Vivek Singh

Prodigy 180 points

Hello Vivek,

OK. We will implement the watchdog reset.

You are correct. We still got an FPGA lockup when we removed the write to the counter registers and implemented the watchdog reset.

The history behind our discovery that counter two influenced this was our temporary implementation of a 28 second timeout and retry of the sequence that was locking up. That's where the 28000 came from. We implemented the retry, and were surprised to find that it never got called.

We are using timer 0 as a delay timer when we need to wait for the A/D converters, etc. We have not tried using timer 1. Nor have we tried values other than 28000. Right now, we have only the writes to 0xC12/0xC13 during our boot. The remaining timer two registers are left at their default values. (You are correct, these are the period registers.)

We have not seen a single lockup since we added the register writes. We don't need the timer for anything else, so this is not a problem. It is a mystery, though.

Thank you for your help.

Regards,

Chris

0 Vivek Singh over 9 years ago in reply to Chris Harthan

TI__Guru** 109105 points

Chris,

Thanks for providing the clarification.

I had one more question - "Also when you say timer two is not used. does it mean, TIMER interrupt is not enabled or timer has been stopped from running (by setting the TSS bit in TIMERxTCR register) ?"

There should not be any relation between TIMER and the functioning of XINTF. I am thinking that error might be going away because of this function call which changes the timing a bit. So instead of writing to TIMER register if you insert same number of NOP instruction inside this function, you may not see the error.

Will it be possible for you to try this?

Regards,

Vivek Singh

0 Chris Harthan over 9 years ago in reply to Vivek Singh

Prodigy 180 points

Hello Vivek,

I would have to look at the default settings in the data sheet to answer this. We are only writing the values shown in the original snippet of code. All the other registers relating to timer two are left at their default settings.

We thought the same thing. We ran just the sort of experiment you proposed, and it had no apparent effect. It takes many seconds for our system to configure all the A/D converters. We moved the writes to the period registers early in the boot sequence, only one time. The XINTF sequence that is problematic is generally minutes later and is unchanged between the failing and non-failing scenarios.

I agree that this makes no sense, but it is repeatable on every unit we have tried.

Regards,

Chris

0 Chris Harthan over 9 years ago in reply to Vivek Singh

Prodigy 180 points

Hello Vivek,

Here is some more information about the writes to timer two registers. This is the code that runs at boot-up. You can see that we have commented out all but the writes to 0xC12/0xC13. We didn't believe that the problem was fixed, and were trying to narrow down which of the register settings were effecting this. We are going to try writing a 1 to the TIMER2PRD registers and see what happens. I'll let you know how that goes on Monday.

Thanks,

Chris

void StartMsTimer(unsigned long lTimeOut) {
unsigned long ticks;
//unsigned short tick;

    // Reduce counter by factor of 1000 for ms (1000-1 = 999 = 0x3e7)
    // low prescaler

// COMMENTED OUT FOR TEST
///    *(volatile unsigned short *)0x0c16 = 0xe7;

    // high prescaler
// COMMENTED OUT FOR TEST
//    *(volatile unsigned short *)0x0c17 = 0x3;

//    tick = *(volatile short *)0x0c16;
//    sprintf(szOneLine,"C16 %x%s",tick,szNL);
//    cmdOut(0,szOneLine);

//    tick = *(volatile short *)0x0c17;
//    sprintf(szOneLine,"C17 %x%s",tick,szNL);
//    cmdOut(0,szOneLine);

    // now ticks are the number of ms * 150
    ticks = lTimeOut * 150L;

    *(volatile short *)0x0c13 = (ticks >> 16) & 0xffff; // hi
    *(volatile short *)0x0c12 = ticks & 0xffff;            // lo

    // Start timer 2 and with interrupts disabled
    // bit 15 = 1, bit 14 = 0, bit 5 = 1, bit 4 = 0,

    // COMMENTED OUT FOR TEST
//    *(volatile short *)(0x0c14) = 0x8020;

    // COMMENTED OUT FOR TEST
//    *(volatile short *)(0x0c14) = 0x8030;
}

0 Chris Harthan over 9 years ago in reply to Vivek Singh

Prodigy 180 points

Hello Vivek,

We had some interesting results from our testing.

We tried setting the 0xC12/0xC13 registers to 1, and found that we could not read the A/D converters at all. The initialization was all correct, but when we tried to read data we had lockup. The difference between the configuration and reading data is that our interrupts are enabled during the taking of data. It appears that the apparent XINTF problems are a symptom, and the root cause may lie with the interrupts.

We next tried setting 0xC12/0xC13 to zero, which is the power-up state. This worked, and has not failed in 72 hours. It's still a bit of a mystery as to why a written zero behaves differently than a power up zero. We will try reading out the value before we set it, to make sure that it really is zero after boot.

It makes much more sense that this is an interrupt related issue. If we were having XINTF issues, I would expect problems with our SRAM and Ethernet interfaces, too. When we have the time, I will get back to you with a description of our interrupt implementation.

Best Regards,
Chris

0 Vivek Singh over 9 years ago in reply to Chris Harthan

TI__Guru** 109105 points

Chris,

Thanks for trying out these experiments.

On below point,

We next tried setting 0xC12/0xC13 to zero, which is the power-up state. This worked, and has not failed in 72 hours. It's still a bit of a mystery as to why a written zero behaves differently than a power up zero. We will try reading out the value before we set it, to make sure that it really is zero after boot.

The power-up state (reset value) for register TIMER2PRD (0xC12) is not zero but 0xFFFF. When you set this to value 0x0, the timer will not generate any interrupt. With any other value, timer will generate periodic interrupt based on the default value (or written value) in these registers.

Regards,

Vivek Singh

0 Chris Harthan over 9 years ago in reply to Vivek Singh

Prodigy 180 points

Hello Vivek,

I had version B of the SPRUF that states that it has a value after reset of zero.

The formatting is a mess, but here is the text from the PDF...

Figure 3-23. TIMERxPRD Register (x = 1, 2, 3)
15 0
PRD
R/W-0
LEGEND: R/W = Read/Write; R = Read only; -n = value after reset
Table 3-21. TIMERxPRD Register Field Descriptions
Bits Field Description
15-0 PRD CPU-Timer Period Registers (PRDH:PRD): The PRD register holds the low 16 bits of the 32-bit period. The
PRDH register holds the high 16 bits of the 32-bit period. When the TIMH:TIM decrements to zero, the
TIMH:TIM register is reloaded with the period value contained in the PRDH:PRD registers, at the start of
the next timer input clock cycle (the output of the prescaler). The PRDH:PRD contents are also loaded into
the TIMH:TIM when you set the timer reload bit (TRB) in the Timer Control Register (TCR).
Figure 3-24. TIMERxPRDH Register (x = 1, 2, 3)
15 0
PRDH
R/W-0
LEGEND: R/W = Read/Write; R = Read only; -n = value after reset

This is making more sense. We wrote our own interrupt handling software and ignored timer 2 altogether. Apparently, timer 2 is preempting our process. It sounds like we can fix our problem by writing zero to 0xC12. We thought timer 2 was shut down at power up.

Thank you for your help. This was a strange problem.

Best Regards,

Chris

0 Vivek Singh over 9 years ago in reply to Chris Harthan

TI__Guru** 109105 points

Chris,

Glad to know issue is resolved. You could also disable the timer from running by setting the TSS bit in TIMERxTCR register to '1', if needed.

Regards,

Vivek Singh

C2000™︎ microcontrollers

C2000 microcontrollers forum

F28335 XINTF Effected by Counter Two Divider