TMS320F28069: TMS320F28069FPZT

Michael,

Thanks for reaching out. 

I did some digging in my emails with the customer, this ended up being a external crystal(clock) related issue.  As we changed temperatures certain crystals were not starting up properly.  There were some dependencies on load capacitance being used, and the crystal vendor(this was changed at some point in the product life cycle, and then the issue cropped up).

Are you using an external clock with the C2000 MCU or just the internal 0-pin oscillator.  If the internal 0-pin, then the issue would be something else.

Best,

Matthew

In our case it is not a clock issue. CPU doesn't seem to get through initialization code after power up. Not always. But here comes the kicker - it seems to be temperature related, and compiler version related. We didn't really make the connection yet between the two!! ADC setup register don't get set, therefore main interrupt doesn't run. We evaluate DSP with different date codes, different compiler versions and also bring temperature into the mix. 

Michael,

Compiler version thrown into the mix would imply some slightly different instructions have caused this to appear.  If you monitor XRSn do you see if go active(watchdog tripping) when trying to boot at the "bad" temperatures.

I'm wondering if some extra instructions may be pushing us over the WD timeout, if enabled.

You could look at the .map files of both compilers to see if there is some noticeable difference in code sizes in different regions.

The compiler shouldn't have any effect on placement, that is the linker, so I would doubt that something that was running from RAM is now in flash, i.e. slower, etc.

Can you give some more background on your initialization, PLL settings, clock source, etc?

Best,
Matthew