AM2432: RESETSTATzL pulse width, RESETSTATz low（tW (RST9)） does not meet specification

Hi Zhannglongc,

The RESETSTAT low duration is more like a parameter that the SoC must be able to provide, rather than a requirement from the user. It is up to you if that small deviation is an issue for the external circuitry that uses/monitors RESETSTAT .

Reasons that may result in deviations that I can recall:

- System clock may not be close enough to 25 MHz

- MCU_PORz low pulse doesn't meet specs. Please see figure 6-5.

- Measuring error may add up

Regards,

Stan

Hi Stanislav Stilyanov :

    1、we  tested our System clock , the frequency Tolerance ＜30ppm,according we test tW=158us caculate the S is 39.1ns，which beyond 30 ppm,in addition to ,we test RST8 is meet  specifications.

    2.Our design the MCU_PORz is controled by RESET IC，we monitoring 0.85V,when 0.85V power good the signal of RESET be releast ,the MCU_PORZ synchronization be releast，so the MCU_PORz did't  be pulled low，I think MCU_RESETSTATz and RESETSTATz been warm reset.

    Can you test in your lab? weher the EVM has this prolem,thank you.

Hi:

    Any progress on this issue?I used a frequency meter to test the clock accuracy of my module and the parameters of RESETSTATz RST9 as shown below:

Figure 1 1CPU_CLK and  RESETSTATz RST9=157.5us

NOTE:The RST9=161.6012us calculated based on the test clock frequency is obviously a big error from the RST9 of my test RESETSTASz signal, so it's not a clock precision effect.

Figure 2 2CPU_CLK and  RESETSTATz RST9=157.9us

NOTE:The question is the same as above

Hi Zhanglong,

For some reason I'm not observing the RESETSTATz low waveform. I will try on another board. Meanwhile, can you please let me know what device(s) is/are connected on RESETSTATz on your board? Are you experiencing issues (e.g. they are not being reset properly) with those device(s)?

Thanks,

Stan

Hi：

   I checked the reason for this reset signal, and saw that the am2432 user manual states that a hot reset is performed roughly after a few hundred ms of MCU_PORz release (this time is what I found in my testing)。

The RESETSTATz signal of My device is connecte to FLASH RESET Pin,the falsh use to memery my device  BOOT and APP.

Hi Zhanglong,

Can you tell us the Flash device part number?

Hi Stanislav Stilyanov:

     My device's Flash number is GD25B512MEBIRR.

Hi Zhanglong,

"RESETSTATz RST9=157.9us  being shorter  than expected in datasheet RST9=161.6012us " - does this affect something in your design? For example any other devices than the Flash memory. I can see from the Flash datasheet that the chip requires min. 1 us reset signal for proper internal reset therefore there is no problem for Flash.

Hi Stanislav Stilyanov:

     "RESETSTATz RST9=157.9us is meet to my device flash reset requirens,but our company test team thinks that RESETSTATz low level time does not meet the AM2432 datasheet requirements(161.6012), we need to give an explanation of what causes this parameter does not meet the specification, so I need your help, I don't think this has anything to do with my design, it's an internal decision of the chip.

Hi Zhanglong,

What is the initial software you are running , if any?

zhanglongc said:

 I checked the reason for this reset signal, and saw that the am2432 user manual states that a hot reset is performed roughly after a few hundred ms of MCU_PORz release (this time is what I found in my testing)

I think this should not be the case. I think this is an internal reset to R5 CPU only and this reset should not be displayed on RESETSTATz pin. Also, I don't observe RESETSTATz assertion on EVM.

Hi Stanislav Stilyanov:

    we have run the initial software，in addintion to i try only down null bootloader on my device ,also i can capture RESETSTATz singnal,but i can't capture RESETSTATz singnal on EVM(only down null bootloader),so So I'm also confused as to what the difference is between the two and why the results are different.

Hi Zhanglong,

You may want to check RST_SRC register status. It logs the last reset reason and can give a clue.

Here is the list of reset sources that can reset MAIN domain:

MAIN Domain Resets
• Power-On-Resets
– MAIN domain software POR reset
– MAIN domain hardware POR reset generated by MCU_PORz pin
• Warm Resets
– RESETz_REQ device pin
– MCU domain warm reset will also generate a MAIN domain warm reset

MCU Domain Resets
• Power-On-Resets
– MCU_PORz device pin: This power-on-reset will reset the entire device including MCU and MAIN domains.
• Warm Resets
– MCU_RESETz device pin
– MCU domain software warm reset
– MCU domain ESM error reset
– SMS cold reset

Hi Stanislav Stilyanov:

   Sorry, I made the mistake of replying incorrectly above ,RESETSTATz and VCCIO3.3 power-up time interval is too short, so I ignored it, today I retested the EVM (test point TP68), and found that the EVM is also the same presence of the signal, and the low time of 157us, also does not meet the specifications, as shown in the following figure shown in the 2 show, the trouble is that you test your EVM (you can set the oscilloscope to falling edge triggering).

Figure1 the replying incorrectly above

Figure2  the RESETSTATz retested  signal of EVM

Hi,

Is this waveform (Figure 1 the RESETSTATz singal POWER UP) the MCU_PORz waveform?

Thanks,

Stan

Hi:

   No,this waveform is the RESETSTATz singal.

Hi Zhanglongc,

The ticket owner is out of office today. He will be back tomorrow and reply to your question.

Kind Regards,

Anastas Yordanov  

Hi Zhanglong,

Can you please capture RESETSTATz along with MCU_PORz? Like below figure?

Thanks,

Stan

Hi:

   I capture MCU_RESETSTATz and RESETSTATz along with MCU_PORz,As shown in the figure below.

Hi ,

On your last capture I can't see the low RESETSTATz pulse from your initial question:

Can you please re-test RESESTATz + MCU_PORz with the low pulse visible?

Hi:

   the low RESETSTATz pulse occur roughly 500 ms after RESENTSTATz is powered up, so the waveform above can't capture.

Did you measure this waveform in EVM, and did EVM download the bootloaders? If there is no bootloaders, the low level of RESETSTATz is not captured.

Hi Zhanglong,

Ok, then this is a software-generated reset.

What bootloader/OS you are using?

Can you share the BOOTMODE pin settings?

Thanks,

Stan

Hi:

Stanislav Stilyanov said:

Ok, then this is a software-generated reset

Yes,I also think this is a software-generated reset ,Did you find out why you didn't meet the specs?

Stanislav Stilyanov said:

What bootloader/OS you are using?

Our bootloader as as shown below，our os:Real Time-Thread

Stanislav Stilyanov said:

Can you share the BOOTMODE pin settings?

Our  bootmode pin set as as shown below,Primary bootmode is OSPI,and back up bootmode is UART.

This problem has been going on for a long time and has affected our project schedule, please give me a conclusion as soon as possible, thanks!

Hi Zhanglong,

Thank you and understand.

I understand the measurement you are seeing is during MCU_PORz.

We expect to have some difference in timing, and this should not be a concern to hold the board design progress. I am checking internally on the expected variation.

In the mean time if you have a provision to do a cold reset, can you do a fast reset - just press and remove and a long press reset and measure the RESETSTATz output.

Regards,

Sreenivasa

HI Kallikuppa Sreenivasa

Thank you you reply.

Kallikuppa Sreenivasa said:

I understand the measurement you are seeing is during MCU_PORz.

NO.I measurement not during MCU_PORz，MCU_PORz has been released。

Kallikuppa Sreenivasa said:

In the mean time if you have a provision to do a cold reset, can you do a fast reset - just press and remove and a long press reset and measure the RESETSTATz output.

 In the mean time we can't do a cold reset，However, we perform a hot reset during a firmware upgrade, and the waveform is shown below, because the RESET_REQz pin has a filter capacitor, the falling edge of the signal is relatively slow.

Hi Zhanglong,

Thank you.

Kallikuppa Sreenivasa said:

I understand the measurement you are seeing is during MCU_PORz.

Noted. Cased on the waveform it looks like the time measurement was after the MCU_PORz goes high 

zhanglongc said:

In the mean time we can't do a cold reset，However, we perform a hot reset during a firmware upgrade, and the waveform is shown below, because the RESET_REQz pin has a filter capacitor, the falling edge of the signal is relatively slow.

A warm reset should be Ok.

The LVCMOS input slew is expected to be less than 1000ns. For the reset inputs, the slew is recommended to be much less (~100ns) since the internal reset could glitch.

With the slow ramp, the RESETSTATz measurement may not be repeatable - can you measure the RESETSTATz output after pressing the RESET_REQz for a short time - some ms and long time - ~ 2 seconds and see if you see any difference the the RESETSTATz timing.

Regards,

Sreenivasa

Hi:

Kallikuppa Sreenivasa said:

With the slow ramp, the RESETSTATz measurement may not be repeatable - can you measure the RESETSTATz output after pressing the RESET_REQz for a short time - some ms and long time - ~ 2 seconds and see if you see any difference the the RESETSTATz timing.

 Sorry,my device is not equipped for such a test and cannot be tested.

Hi Zhanglong,

zhanglongc said:

because the RESET_REQz pin has a filter capacitor, the falling edge of the signal is relatively slow.

Can you unmount the capacitor and measure the RESETSTATz again?

Thanks,

Stan

Hi Stan

I checked with customer, they do not have test environment to test this.

I want to check 2 things:

1. Can we test the same phenomenon on AM243 EVM with TI Bootloader? Customer mentioned that they can test it on EVM.

2. If yes,what is the reason of this phenomenon?

I have escalated this issue internally and hope we can help customer solve this ASAP. Thanks for your support as always.

Thanks

Zekun

Hi Zekun,

1. Yes, will test this on EVM.

2. We don't know because RESETSTATz is internally generated and should be 4040 * 25-MHz clock cycles time, but customer is seeing slightly less. This should not be an issue because they only use RESETSTATz to reset theit flash memory which requires only 1-us of reset asserted.

Yes, I agree , the shorter reset duration time should be addressed internally.\ and may require datasheet update or else.

Regards,

Stan

Hi all,

I got the scope screenshots. Please note that the measurements were made on AM64x EVM.

RESETSTATz measurements.zip

Regards,

Stan

Hi Stan

2. We don't know because RESETSTATz is internally generated and should be 4040 * 25-MHz clock cycles time, but customer is seeing slightly less. This should not be an issue because they only use RESETSTATz to reset theit flash memory which requires only 1-us of reset asserted.

I checked with your team via weekly meeting. Do we have plan to update datasheet based on your reply?

I think if we can notify customer this is an normal phenomenon, then customer can close this issue because this issue do not impact customer application. All they want is a clarification.

Regards

Zekun

Hello Zekun, 

Based on the initial discussion with design variation is the RESETSTATz min timing is expected.

We are working with the design to understand more on the expected variation and the min value.

We may be able to confirm the data sheet update plan once we close the discussion.

This is likely to take some time.

Regards,

Sreenivasa

Hi Sreenivasa

Thank a lot, wait for your reply.

Regards

Zekun

Hello Zekun, 

Thank you. Will do.

Regards,

Sreenivasa