CCS/TMS320F2808: Causes of trouble while using TMS320F2808

Kang,

You mention that if the ADC value is out of range the F2808 will transmit this value across a comms channel, I assume to some system master.  Are you able to read the value sent from the F2808 comms channel and is it in/out of range?  How are you verifying that the ADC read value is OK in the system?

I'm not sure what is meant by damaging the device by the memory programmed to the F2808.  The only type of issue that can occur with regard to memory is if the flash is mis-programmed(typically by power interruption during programming) and the device Code Security Module gets locked.  At that point the device memory cannot be read externally if the password is unknown.  Otherwise I don't know of any issues that could be caused by a bad memory write to the F2808.

Best,

Matthew

MatthewPate
Thanks for the answer.

Sending the AD value to the communication channel means that the value in the specified range of this value is judged as normal / abnormal and is sent by CAN communication.
This value is entered normally because it is confirmed that it works normally in the part that performs another operation with this value.
It is also normal to check it in hardware.

I uploaded the program again.
The same symptoms still occur

When re-uploading, it was confirmed that it was normal.

So, as in the above, making another judgment with one AD value is inquiring what the cause is.

The abnormal behavior of this product is that it occurs occasionally.
If the power is first applied and tested, it operates abnormally.
However, if the power is turned on / off repeatedly and tested several times, it will operate normally.
The program source code has been confirmed as normal.

This symptom occurs only with one product.

What kind of defect can cause this symptom?.

This is an inquiry to find the cause of malfunction.

Kang,

Thank you for the additional detail, I understand that you are seeing an issue with one device where all other devices don't behave this same way.

Given that the MCU is handling the bulk of the system operations the failure symptom is almost always detected here.

I would like to ask to try what we call and "A" "B" swap; that is to take a working PCB/MCU and swap the C2000 from this board to the PCB that is showing the issue and remove the MCU from the PCB showing the issue and place it on a known good PCB.  Then rerun the tests.

I want to do the above to be sure that the issue is with the C2000 MCU or the PCB.

Once we have confirmed this information we can proceed with a debug/defect ID flow for the MCU if it is the cause.

Best,

Mattheww

Kang,

Thanks for the clarification.  There is not any known issues with this device as shipped from TI.  Every device that is sold is tested and expected to meet the performance numbers listed in its DS. The most typical issue we see is if a pin or the device has been exposed to a voltage in excess of those supported in the datasheet(overvoltage event).  These typically destroy the ESD protection diode inside the device and make the pin an "open" or in the case of the votlage rail make the device completely non-functional.

From your observation,  it appears that the MCU is working operationally, but having a specific issue with an ADC conversion(or perhaps the CAN communication).

Now that we have traced the issue back to the MCU there are two paths:

1)Continue to debug to further isolate the failure on the device you have.  Based on the info so far I would start looking at either the ADC or CAN modules to see if we can get good behaivor if we change paramters like input channel(different ADCIN pin) or pin used for CAN.  This will require SW modification(and use of CCS IDE) and potentially HW modification.  If your environment is completely production related, you may not have access to perform these steps, please let me know.

2)Using the information provided on this page http://www.ti.com/support-quality/additional-information/customer-returns.html we can begin the process of getting the device back to TI for some type of failure analysis.  Ultimately if the device is damaged we can usually determine if a certain pin is responsible or other module is not behaving as it should be.  Any additional info you or your team can give TI on operation conditions(how long the device was in operation before failure, has the device been exposed to over voltage, and what pins) is helpful.

Let me know which path is most preferable to you and I can assist moving forward.

Best,

Matthew