TMS320F28379S: TMS320F28379S: Comparator toggling without input at cold temperatures

Hi,

Apologies for delay assigning to CMPSS block owner. 

BR,

Nilesh 

Hi Thomas,

Thanks for the detail problem statement. Do you have an estimated age of the devices? I'm wondering, in your present code, is there any calibration routines that are performed at startup or throughout operation? Both age and temperature can have an impact on the device, especially for the analog portions which are more sensitive, but these are usually trimmed and accounted for during testing of the chip. Including a periodic calibration routine also may have an impact, since you say that this happens once the device reaches the colder temperature and only stops after power reset

Regards,

Peter

Hi Peter,

We are encountering this issue on first-use with devices with date codes 41 and 33. Other tested date codes (1C, 38, 31) do not exhibit the problem. The issue occurs immediately after the comparator is configured in the firmware during cold-start turn-on.  Adjusting the trip threshold has no effect, so it is unclear whether a calibration routine would make any difference. Currently, we do not run calibration routines for the affected comparators.

Key findings since my initial post:

• The issue appears immediately after comparator configuration; changing the trip threshold has no impact.
• Initialization timing is identical between affected and unaffected devices.
• The problem follows the processor when transferred to a known-good PCB.
• Introducing a ~400 ns delay between enabling and configuring the comparator (as in my original code snippet, lines 1 and 2) eliminates the issue, though the root cause is unknown and this cannot be considered a long-term solution.

According to the errata (Table 5-54), the comparator power-up time specification was changed. Could you confirm when this change was introduced and whether it might account for the cold-start behavior we are seeing?

Hi Thomas,

Thomas MacGregor said:

Introducing a ~400 ns delay between enabling and configuring the comparator (as in my original code snippet, lines 1 and 2) eliminates the issue, though the root cause is unknown and this cannot be considered a long-term solution.

This is an important point I want to highlight. There is a recommended startup time for the CMPSS DAC, for good measure in our auto-generated code, we enable a 500us startup delay. See the code snippet below

void myCMPSS0_init(){
    //
    // Sets the configuration for the high comparator.
    //
    CMPSS_configHighComparator(myCMPSS0_BASE,(CMPSS_INSRC_DAC));
    //
    // Sets the configuration for the low comparator.
    //
    CMPSS_configLowComparator(myCMPSS0_BASE,(CMPSS_INSRC_DAC));
    //
    // Sets the configuration for the internal comparator DACs.
    //
    CMPSS_configDAC(myCMPSS0_BASE,(CMPSS_DACVAL_SYSCLK | CMPSS_DACREF_VDDA | CMPSS_DACSRC_SHDW));
    //
    // Sets the value of the internal DAC of the high comparator.
    //
    CMPSS_setDACValueHigh(myCMPSS0_BASE,0U);
    //
    // Sets the value of the internal DAC of the low comparator.
    //
    CMPSS_setDACValueLow(myCMPSS0_BASE,0U);
    //
    //  Configures the digital filter of the high comparator.
    //
    CMPSS_configFilterHigh(myCMPSS0_BASE, 0U, 1U, 1U);
    //
    // Configures the digital filter of the low comparator.
    //
    CMPSS_configFilterLow(myCMPSS0_BASE, 0U, 1U, 1U);
    //
    // Sets the output signal configuration for the high comparator.
    //
    CMPSS_configOutputsHigh(myCMPSS0_BASE,(CMPSS_TRIPOUT_ASYNC_COMP | CMPSS_TRIP_ASYNC_COMP));
    //
    // Sets the output signal configuration for the low comparator.
    //
    CMPSS_configOutputsLow(myCMPSS0_BASE,(CMPSS_TRIPOUT_ASYNC_COMP | CMPSS_TRIP_ASYNC_COMP));
    //
    // Sets the comparator hysteresis settings.
    //
    CMPSS_setHysteresis(myCMPSS0_BASE,0U);
    //
    // Configures the comparator subsystem's ramp generator.
    //
    CMPSS_configRamp(myCMPSS0_BASE,0U,0U,0U,1U,true);
    //
    // Disables reset of HIGH comparator digital filter output latch on PWMSYNC
    //
    CMPSS_disableLatchResetOnPWMSYNCHigh(myCMPSS0_BASE);
    //
    // Disables reset of LOW comparator digital filter output latch on PWMSYNC
    //
    CMPSS_disableLatchResetOnPWMSYNCLow(myCMPSS0_BASE);
    //
    // Configures whether or not the digital filter latches are reset by PWMSYNC
    //
    CMPSS_configLatchOnPWMSYNC(myCMPSS0_BASE,false,false);
    //
    // Enables the CMPSS module.
    //
    CMPSS_enableModule(myCMPSS0_BASE);
    //
    // Delay for CMPSS DAC to power up.
    //
    DEVICE_DELAY_US(500);
}

If you follow the order of configuring the CMPSS module in the example, mainly with the enable and delay at the end of the configuration, does this also eliminate the issue?

I'm also interested if you can check the REVISION ID of the devices and make sure they are all the same silicon revision

Regards,

Peter

Hi Peter,

A couple of corrections/clarifications from my previous post:

• The issue has only been observed on date code 41 devices (not 33 as previously mentioned). We currently have two affected units with the following markings: 3LC-41A4Y7W and 3LC-41A731W.
• The table I was referencing is from the datasheet SPRS881K, section 10.2.1.1, where the comparator DAC power-up time is specified as 500 µs. Could you confirm when this value was changed from the previous 10 µs specification?

Regarding your suggestion, moving the CMPSS Enable call to the end of the configuration sequence does eliminate the issue, even without adding the 500 µs delay. However, it’s still unclear what specifically is causing the unintended toggling of the COMPSTS register, and why this has not been seen before.

Further testing shows that COMPHOUT does not toggle during the failure condition when muxed to a GPIO. This points to the issue being related to the digital filter that drives COMPSTS.

We confirmed this by setting CTRIPOUTHSEL to 2 (output of the digital filter) instead of 0 (raw comparator output). When measured on a GPIO with an oscilloscope, the digital filter output is oscillating at ~100 MHz during the failure condition.

Hi Thomas,

I'll need to track down some of our inventory experts as it's difficult to to know just by the date code - these could possibly be produced at 2 different Fabs which may link to the difference in behavior. I assume the revision IDs are the same but would be good to double check.

Our guidance is typically to program peripherals before enabling them, my guess is that enabling causes some edge condition where CMPSS gets set while some necessary register is being changed and causes an issue with the module

I reviewed literature bug repository and didn't see any reports of the 10 -> 500 us being documented so I can't point to a specific date when this was documented.

Regards,

Peter

Hi Peter,

Thank you for the clarification. We'll continue working on narrowing down the date code information on our side as well.

Some items we would like to confirm regarding the 500us power-up time:

• If this delay is not observed at the comparator enable, would any resulting undesirable behavior only be expected within the initial 500us window?
• Would violating this requirement cause the module to exist in this faulty state beyond the startup period?

Our current understanding of this spec is that the 500us period ensures stable output during the power-up window, and after this time the comparator/DAC should function correctly regardless of initialization order. Could you confirm that is correct?

Hi Thomas,

Thank you for your patience. See the below responses to your question

Thomas MacGregor said:

If this delay is not observed at the comparator enable, would any resulting undesirable behavior only be expected within the initial 500us window?

The guidance likely stems from the fact that CMPSS is largely used for safety purposes to avoid overcurrent conditions, so trying to use the CMPSS before it's "ready" could lead to system failure and I believe that undesirable behavior is limited to this startup period.

Thomas MacGregor said:

Would violating this requirement cause the module to exist in this faulty state beyond the startup period?

I couldn't say for certain on this as I'm not able to locate any details regarding the situation as to why the startup window time was increased. It's likely based on what you detailed in your original findings that any use of the CMPSS during its configuration phase could have an impact on future behavior of the comparator module. I would say that for startup phase, this risk is less likely since no register accesses are occurring during the operation.

Regards,

Peter

Hi Peter,

Thank you for the continued support on this. We’ve gathered some additional data points that may help:

• We have now confirmed failures on devices with markings 3LC-427FYW and 3LC-41A4YCW, which suggests the issue may be linked to the wafer fabrication code (3L).

• We have verified no problems on devices with the following markings:

  • $7C-31AXGVW

  • YFC-8BA4DNW

  • YFC-38ASFHW

While we have isolated four device batches with wafer fabrication code 3L, not every device in those batches exhibits the failure. Since the failure mode is consistent per device once observed, would it be safe to assume that screened, passing devices from these lots are reliable to use in production?

Finally, since the 10 µs → 500 µs change is not tracked in the bug repository, can TI confirm whether all silicon lots have always required ~500 µs, and that the 10 µs value was simply a documentation error?

Hello, 

The expert will be out of the office until 9/2/25. 

Regards,

Carlos

Hi Thomas,

Thomas MacGregor said:

Since the failure mode is consistent per device once observed, would it be safe to assume that screened, passing devices from these lots are reliable to use in production?

Based on your testing, it does seem that this behavior is linked to the manufacturing of the device. I can't say for sure about this part since other factors such as board manufacturing, metastability, and age may affect the device. 

Thomas MacGregor said:

Finally, since the 10 µs → 500 µs change is not tracked in the bug repository, can TI confirm whether all silicon lots have always required ~500 µs, and that the 10 µs value was simply a documentation error?

I think this is safe to say since all of our code generation tools for all of our devices use this buffer duration

Regards,

Peter

Hi Peter,

Thank you for your help on this.

Going forward we’ll make sure to follow the recommended configuration sequence. For implementation clarity: does the 500 µs delay need to be applied individually for each comparator (e.g., configure → enable → wait 500 µs for CMPSS1, then repeat for CMPSS2, etc.), or is it sufficient to configure and enable all the comparators in sequence and then apply a single 500 µs delay at the end?

Hi Thomas,

The 500us delay should ideally happen right after enabling the CMPSS module, but it only needs to be done a single time to allow all the CMPSS DACs to power up. So the optimal method would be to configure each CMPSS module. Then after configuring all the CMPSS modules, subsequently enable the CMPSS modules one after the other. Then you can apply a single 500us delay after these enable calls.

The 3L fab wafer code corresponds to one of our newer fabs where we have started producing the F28379S device so I am working with our quality team on this

Regards,

Peter

Hi Peter,

Thank you for the clarification. As for the current projects we have, I'm curious to see if there is a link between wafer code and the problem we are seeing.

Hi Thomas,

There likely is, we are investigating this internally and you have probably been requested to issue a return for the affected devices so we can run some analysis on these devices. Thanks!

Regards,

Peter