TMS320C28346: No I2C booting after multiple hardware resets?

So, summary of the problem is this: While the on-chip I2C bootloader is reading from an external I2C EEPROM, if multiple resets happen (generated by the STM1816TWX, owing to power-supply noise), the 28346 locks up. In this situation, even activating -XRS does not bring the chip out of this state and one needs to cycle power. Is my understanding correct?

Please do provide the scope plots.

Dear Hareesh,

thanks for the fast reply. Yes your summary is correct!

Attached please find some scope plots.

Bes regards,

Fabian Seebauer

I think it is not so much the fact that there have been multiple resets, but the fact that there was excessive noise on the power supply that put the device into an indeterminate state. I don’t know how your reset circuit is configured, but if you send a clean reset pulse multiple times, I doubt if we will see this issue. You could generate such a clean pulse from a GPIO pin of another device.

Here another scope plot where you can see the 3.3V in detail. I applied a dc offset in the scope and increased the sensitivity to 100mV for the 3.3V probe. The min-max aplitude is roughly 200mV from the dc-dc converter. Additionally i have relatively long wires at my test-build.

I think this should not be the problem. The reset-signal (blue) goes straight down to GND and remains there.

Additionally investigations show, that the core-supply voltage has to drop down for recovering the dsp. The 3V3 and the 1V1 supply are generated via DCDC from 5V. If there are voltage dips on the 5V supply, the 3V3 supply drops before the 1V1 voltage. If the voltage dip of the 5V is long enough the 1V1 also drops unter the dsp specifications and the dsp restarts with normal operation.

So with hardware resets in the I2C bootloader the dsp can get in un indetermined state which can only be recovered then the corevoltage drops under the limit and the dsp core reboots.

Do you have any additional hints or work-arounds for this problem? Or can you rebuild such a behavior?

It appears the DSP operates for some time outside of the datasheet specifications, which puts it in an indeterminate state. When the rails rise back to datasheet limits, the DSP is unable to resume normal operation. The only workaround I am able to suggest is to ensure the rails are always within specs.

yes... but this does not solve the problem;-) I think we have to make a circuit for complete power-down-power-up, then there is a event on the 3V3 supply line. This is not very satisfying....

Yes, it appears so. I regret I don't have a better solution.

Dear Mr. Hareesh,

yes, but the problem isn't solved! Ther is a short break in the supply, BUT the device should reboot after a correct reset signal out of every condition. This is why it is called reset I think.

Have you tested on of your dsp's in your laboratory if the problem is also present there?

Best regards,

Fabian