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.

TMS320F28035: Interference during programming causes the chip to lock up, how to avoid this

Part Number: TMS320F28035

Hi experts,

My customer find that TMS320F28035 usually lock up because of interference during burning, they want to know how to avoid this.

I heard that 3th generation C2000 is not like this. How do we optimize it, and how do 3th generation C2000 recover if it is disturbed during the burning process?

Thanks and regards,

Jim

  • Jim,

              Being affected by interference during programming suggests that the circuit is vulnerable to EMI, in general. What I am saying is that the circuit can be affected during normal operation as well. Of course, if the programming process is interrupted, that could corrupt the password locations permanently locking the device. You cannot recover from this. 

    The solution lies in hardening the circuit design to make it immune to the disturbance. The challenge lies in determining precisely how the disturbance impacts the circuit. i.e. in identifying exactly how noise couples into the circuit. In other words, what is the conduit for this noise to get into the circuit and cause the malfunction? Once this is identified, it is relatively easy to come up with the protection solution. Unfortunately, often times, the shortcomings are discovered after the board is made and hence make the redesign of the board necessary. 

    Many books have been written on this topic and many papers published. The actual circuit design, the components used, the geometry of the components, the board layout, the board stack-up, the shielding employed , all play a role in the immunity strength of the design. Debugging such problems is an iterative process and warrant hands-on debug. It is extremely difficult to debug issues like this remotely, without access to the schematics, PCB layout and the hardware itself. In other words, remote debug is not practical. The first task is to find whether the noise is coupled conductively or radiatively into the system. i.e. whether the issue at hand is one of conducted immunity or radiated immunity. Once this is identified, we need to identify the entry point of the noise into the system. Only then can we come with a solution. Problem could be related to insufficient decoupling/filtering, incorrect layout, improper (or lack of) shielding etc. There are numerous resources online that deal with this. Hard to explain them in a post. Please google "EMC shielding" for helpful links.

    I heard that 3th generation C2000 is not like this. How do we optimize it, and how do 3th generation C2000 recover if it is disturbed during the burning process?

    In the 3rd generation C2000 devices, we mitigated this problem by moving the passwords from the main Flash array to the OTP. So, even if the Erase/Program operation of the main Flash array gets interrupted, the password locations in the OTP does not get disturbed.