AM6442: Something Wrong in the Delay time RST12 and RST14 of Reset Switching Characteristics ?

Hello Hideaki

Thank you for the query.

I assume this a custom board that customer is using to make measurements. 

Please help me understand how MCU_RESETz is connected.

Can you please suggest customer to perform the below measurements.

Table 7-6. MCU_RESETSTATz, and RESETSTATz Switching Characteristics

Table 7-8. MCU_RESETSTATz, and RESETSTATz Switching Characteristics

Regards,

Sreenivasa 

Hi Sreenivasa,

Kallikuppa Sreenivasa said:

I assume this a custom board that customer is using to make measurements. 

Please help me understand how MCU_RESETz is connected.

Yes, they’re using their own board. On their board, MCU_RESETz is directly connected with the Switching device and there is no dumping resister. (Only 10K ohm pull-down resister is connected for signal observation.)

FPGA is connected over the Switching device, and FPGA controls reset signal to MCU_RESETz and others via the Switching device.

Actually, they observed the waveforms as one-to-one connection between AM64x and FPGA, because the switching device is on conduction state when FPGA outputs MCU_RESETz signal.

See the attached files for the observed waveforms.

They would like to know why the actual measured values were different from the values described in the datasheet.

Hideaki Matsumoto said:

The following timings are specified in the page 119 of the data sheet.

• RST12 (Delay time, MCU_RESETz inactive (high) to MCU_RESETSTATz inactive (high)) :    Min 38.64us (calculated at a clock frequency of 25MHz)
• RST14 (Delay time, MCU_RESETz inactive (high) to RESETSTATz inactive (high)) :              Min 161.6us (calculated at a clock frequency of 25MHz)

 

However, these actual measured values were 24.38us for RST12 and 145.6us for RST14 which are smaller than the minimum values described in the above table when they actually measured these timings.

Could you please confirm the reason for these differences?

Regards,

Hideaki

Hello Hideaki

Thank you.

I am reviewing the inputs.

Could you please check with customer if they made similar measurements for the below table.

Table 7-6. MCU_RESETSTATz, and RESETSTATz Switching Characteristics

Also can you please request customer to capture the MCU_RESETz and MCU_RESETSTATz with respect to MCU_PORz or PORZ_OUT

Is the waveform captured during power-up or  captured during run time when the MCU_PORz was stable and high for some time.

Regards,

Sreenivasa

Hi Sreenivasa,

Kallikuppa Sreenivasa said:

Is the waveform captured during power-up or  captured during run time when the MCU_PORz was stable and high for some time.

The waveforms which they’ve shared were captured at the power-up.

In the series of reset signal release sequences at power-on,

After MCU_PORz output from FPGA, MCU_RESETz is output from FPGA by receiving POR_OUTz from AM64x.

As shown in the attached images, the rise times of MCU_RESETz and MCU_RESETSTATz with respect to MCU_PORz are 1.022ms and 1.144ms, respectively, satisfying the rise interval specified in Table 7-6 of the data sheet.

(Calculate the min value at frequency 25MHz, S=40ns)

Regards,
Hideaki

Hello Hideaki

Thank you.

I am assuming 7.6 could be the table to refer during power-up.

I assume when there is a cold reset done, some of the warm reset related signals may have propagated.

Would it be possible to generate a warm reset after the system is up and running.

Regards,

Sreenivasa

Hi Sreenivasa,

As mentioned above, the rise times of MCU_RESETz and MCU_RESETSTATz with respect to MCU_PORz are 1.022ms and 1.144ms, respectively, satisfying the rise interval specified in Table 7-6 of the data sheet. That's enough time, 7.8 could be the table to refer in this case. Correct ?

Is it possible to receive a more clear answer, not assumption ?

Regards,
Hideaki

Hello Hideaki

Thank you.

Hideaki Matsumoto said:

That's enough time, 7.8 could be the table to refer in this case. Correct ?

I cant understand the comment, please elaborate.

Please note the connectivity requirements 

Can you confirm if these pin connectivity recommendations.

Can you share the schematics for the connections and help me understand the use case for performing cold reset during power-up.

Regards,

Sreenivasa

Hi Sreenivasa,

Were you able to confirm if there is no typo or misdescription in the page 119 of the datasheet ?

Hideaki Matsumoto said:

The following timings are specified in the page 119 of the data sheet.

• RST12 (Delay time, MCU_RESETz inactive (high) to MCU_RESETSTATz inactive (high)) :    Min 38.64us (calculated at a clock frequency of 25MHz)
• RST14 (Delay time, MCU_RESETz inactive (high) to RESETSTATz inactive (high)) :              Min 161.6us (calculated at a clock frequency of 25MHz)

 

However, these actual measured values were 24.38us for RST12 and 145.6us for RST14 which are smaller than the minimum values described in the above table when they actually measured these timings.

Could you please confirm the reason for these differences?

 

They are concerned about individual differences between devices and the possibility of typo in the data sheets (for example, min and max may be exchanged).

Regards,

Hideaki

Hello Hideaki

Thank you for checking.

I am checking internally and  have not heard back from the expert.

Let me follow-up and update you.

Regards,

Sreenivasa 

Hi Sreenivasa,

Did you get any update from the expert ?

Please follow up this.

Regards,
Hideaki

Hello Hideaki

Thank you for checking.

I have not got any update. Will follow-up and update.

Regards,

Sreenivasa

Hello Hideaki

Please refer input from expert and let me know your thoughts.

The values that are quoted are not actual minimums and were derived from simulation.  They were meant to be approximate delay values, so they should probably be listed as ‘typical’

Is the customer seeing any functional issue, or they just observed these signal measurements?

Regards,

Sreenivasa

Hello Hideaki

Checking if you had any additional query?

Regards,

Sreenivasa

Hello Hideaki

Kallikuppa Sreenivasa said:

Is the customer seeing any functional issue, or they just observed these signal measurements?

Do you have some inputs?

Regards,

Sreenivasa

Hi Sreenivasa,

We're discussing this topic offline and I've gotten your comment below via e-mail. So, please let us know once you get any update from the device expert.

I am checking with the device expert/simulation team on addressing this observations in the data sheet.

Thanks and regards,
Hideaki

Hello Hideaki

Thank you for the note.

The team is discussing and i am following.

I will update you when i get some inputs.

Regards,

Sreenivasa

Hello Hideaki,

Please refer below input i received:

We will review and assess if this should be modified in the datasheet and if a change is required it will be updated in the next revision of the datasheet.

For the time being, customer should not consider these as minimum values but rather typical.

 If there are any functional failures or system impacts please let us know. We need time to assess if this needs to be adjusted in the datasheet.

Regards,

Sreenivasa