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

TMS320F28374S: TMS320F28374S ADC inputs frozen after Flash reprogramming

Daniele Bruno
Prodigy 70 points

Part Number: TMS320F28374S

Hello,

We have a strange problem in a board with a TMS320F28374S microcontroller.

I must say first of all that the board has an interface connector with digital and analog inputs.

Digital inputs are 24Vdc and optoisolated, while analog ones are conditioned by filtering stages based on Operational Amplifiers.

We use the default boot mode, i.e. "Get Mode" to start a little portion of code that serves as Firmware Loader.

This Loader reads data from SCI-D in order to program the true Application Firmware in the Flash.

All this process works fine until the interface connector isn't connected with the external world.

If we drive the inputs (analog and digital) from the interface connector during the process above-mentioned, after having reprogrammed the Flash, some ADC Inputs get stuck at zero.

Doing the same with JTAG doesn't have this effect.

The problem remains even if we remove the connector and replace the microcontroller with another one.

We see with the oscilloscope the analog signal at the microcontroller pin but when we try to read it, we get zero.

Another strange thing is that the reading of the ADC inputs that are remained alive, is affected by a significant offset.

Do you have some suggestions in order to solve this problem ?

Thanking in advance for the attention,

Best regard

  • 0
    TI__Guru 60865 points

    Hi Daniele,

    Are you running the code from the newly updated firmware to determine the goodness of the ADC results?  

    One experiment to untangle whether this is a HW issue (perhaps EOS has occurred during the programming operation) or a SW issue (the programmed flash image is corrupt for some reason) is to run the ADC sampling code from RAM loaded via JTAG both before and after the programming operation.  

    It does sound like it is a HW issue, and if the issue persists even after replacing the MCU, then the issue seems likely to be in the signal conditioning circuits or the analog support circuits.  Some possible places to look might be:

    • Measure the VREFHI voltage before and after the programming operation
    • Inspect and/or replace the bulk capacitor between VREFHI and VREFLO and the decoupling capacitors on the VDDA rail
    • Inspect and/or replace any op-amps in the ADC signal chain along with any passive components
    • Measure the various board supply currents before and after the programming operation
    • Use a thermal camera before and after (and maybe during) the programming operation to look for any hot spots on the board

  • 0 in reply to Devin Cottier
    TI__Guru 60865 points

    Hi Daniele,

    Were you able to determine the cause of this issue?  

  • 0 in reply to Devin Cottier
    Prodigy 70 points

    Hi Devin,

    your suggestion has been fundamental: running the ADC sampling code from RAM loaded via JTAG allowed us to find the problem.

    In the Firmware, the ADC results were multiplied with a set of parameters left uninitialized, so they became zero and tha ADC results too.

    The problem is resolved.

    Thank you for all the attention.

    Best Regards,

    Daniele

  • 0 in reply to Daniele Bruno
    TI__Guru 60865 points

    Hi Daniele,

    Thanks for posting the resolution, and glad to hear things are now working!