TMS320F28P650DK: TMS320F28P650DK Program Running Away

Hi Jeno,

Unfortunately, that fluctuation down to a minimum of 2.5V during power on violates the recommended operating conditions for the device supply voltage of 2.8V.

This will likely cause some effect on the program if it has started execution. The PMM would force a reset in this undervoltage condition. Can you also monitor XRSn during this process?

Is the customer using Internal VREG for VDD supply?

It would also help if they could provide a general power up diagram with the associated timing/connectivity information to better understand where and how the issue is introduced.

Without further information, first recommendation would be to include the additional circuitry needed improve signal stability and provide a clean source at startup. Another option would be to include a reset monitor that would hold the XRSn pin low for some period to allow the source voltage to stabilize before attempting to execute startup.

Please let us know your thoughts on these possibilities and we are happy to explore further options.

Best Regards,

Zackary Fleenor

Thank you,I  will elaborate on this further

1:the  fluctuation down to a minimum of 2.5V maybe due to contactor interference，after i changed a Solid State Relay，There has been no progarm running away in the past few days.also the ethercat network no longer drops out（At first, I thought these were two separate issues），This is just my speculation, and I'll keep an eye on it.

2：I will  monitor XRSn，i will replace the contactor  back to check the XRSn,this is our circuit diagram,i will monitor  C909。

3：YES,Internal VREG for VDD supply，VSS: Low level input

We will not make any adjustments for the time being until we reach a definitive conclusion.

I will contact once I complete the tests.

Sincerely

Hello Wudi,

Glad to hear you are making headway. Please keep us updated with the latest results.

Best Regards,

Zackary Fleenor

One more question：

when i test,i found when XRSn will cause a restart

I noticed that when the program running away problem occurred，the mcu didn't restart，It was more like it froze，It only returns to normal after a power cycle（No watchdog was used）

is that normal If it’s a power supply issue？

After I replaced it with the old contactor, the ethercat network drops out intermittently and randomly，when the latest system crash occurred the XRSn  high level,but the MCU not work untill repower,the ethercat network will cause this problem?

Hey Wudi,

When you say "it was more like it froze", can you explain the operations leading up to that, and how the device behaves at this point?

Can you provide the ethercat/phy connectivity used during testing? I couldn't imagine why issues in the Ethercat network would drive this sort of issue with the MCU.

Is there any reason not to use the Watchdog in this case to prevent the MCU from remaining in an unusable state?

Best Regards,

Zackary Fleenor

We’re not really certain when it happens，only know is the 28P650DK9 not work,include IO，communication

The equipment is in the research and development phase，We have two boards，One of them uses the 280031 for its MCU，And the other one uses the 28P650DK9.When the problem hits，the 280031 is normal but the 28P650DK9 run away,now if we use  contactor,The problem maybe happens once every day.Such a fault occurrence rate is not permissible for a normally functioning piece of equipment.iif it happens very rarely，we will use Watchdog.now we use Solid State Relay test now.

As far as we know, different components（i mean contactor and Solid State Relay） have a significant impact on the power supply，We have now confirmed a power supply issue, but we cannot guarantee that the program is entirely free of problems.

We will continue the testing with Solid State Relay, and if the issue no longer occurs，maybe the problem is electromagnetic interference of the contactor

We want to look for some theoretical backing on this if the power will cause this。

the blue one is 3.3V power for MCU

the yellow one is XRSn

The interference observed on the oscilloscope is caused by the contactor's actuation and release，The interference is even more severe when the contactor releases.

about the ethercat/phy connectivity ，The same circuit diagram as the development board，The suspicion of the network issue arises because the contactor causes disconnections 5 to 10 times a day, while the solid-state relay works without any problems at all.We just suspect a correlation between the ethercat disconnections and the system freezes. 

Hey Wudi,

I would recommend creating another E2E ticket with the relevant PHY team to resolve the network connectivity issue first. If there are still issues with the MCU after resolving this, we would be glad to continue to assist with further debug.

Best Regards,

Zackary Fleenor

ok，get it