Hi
We try to use the nRESET_OUT signal to control our custom circuitry on our board.
The measurements shows the power suppy +3.3V, the SysResetn signal (nRESET_EXT) and the ResetOutn (nRESET_OUT).
We see two pulses, one early when nRESET_EXT is low and a second late after nRESET_EXT is high.
Both pulses worries us a lot.
In the documentation 5.1.3 Power Management Signals you write that the nRESET_OUT is driven low during boot up.
How we can avoid such pulses to get described behavior?
Regards Stefan
Could you share the schematic of the output circuit of nRESET_OUT on your board? Please share also the git diff for device tree, so we can check the changes?
The two pulses have two completely different reasons. Let me explain them independently.
The first one is caused due to a hardware race condition on the module due to the fact that you are holding down the nRESET_EXT (pin 26) during power up. There is a circuit which debounces the nRESET_EXT signal. Unfortunately, the debouncing circuit is sometimes not fast enough to pull down the internal reset line before the PMIC actually releases the reset. The debouncing delay is actually depending on temperature and component tolerances. Therefore, the pulse does not appear on all modules and all conditions. Interestingly, you are the first one who noticed this pulse. I am not aware of other reports. We have been also not aware of this pulse, since we did not test it with the reset button hold down during power up.
The solution would be to reduce the debouncing time. I have created an internal ticket for changing it in the next revision of the module. However, since the Colibri iMX6 is in the production phase, we will only change product version if it is absolutely necessary. This reset pulse at the beginning is not going to cause issues on the module and it is very unlikely that it will cause issues on cusomer carrier boards. Therefore, the priority for this change is low.
The second pulse is created intentionally in order to resolve an issue we had with the hardware version 1.0. The PF0100 PMIC on the module is not capable of generating a reset output pulse if the software is requesting a reset. More information including a workaround can be found in this article: Colibri iMX6 nRESET_OUT Software Reset Workaround. With the Version 1.1 of the Colibri iMX6 module, we included the workaround on the module. There is basically the same circuit on the module. However, there is one little difference. In order to make sure that older BSPs are still running on hardware V1.1, there is a pull down instead of a pull up on the driving GPIO. This means, the reset is directly released, even if the software does not drive the GPIO. This also means, the reset is released before the bootloader has booted. As soon as the bootloader takes control over the GPIOs, it is driving the external reset low again and releases it.
We did not get reports of any issue with this second reset pulse. However, if it creates problems with your hardware, you could remove the second reset cycle from the u-boot. The drawback is that software initiated reset will no longer generate a reset pulse on the external reset.
Thank you for the answers. Can you guide me to the place in the u-boot code and tell me what I have to change. The second pulse is about 120ms after SysResetn is released. But when I do changes in the u-boot
colibri_imx6.c board_init() then this will be only about 350ms after SysResetn is released. Is the code somewhere in the early code or asm code?
In the preView of the attached measurement you can see the Signal TPMReset. You see a low pulse at the right. This is the time when board_init() is executed
I don’t think @peter.tx described what is really going on on the software side. As you may find from the following commit we only ever do a second reset cycle on reboot aka in the not POR case.
Hi Stefan
Thanks for the fix. I am embarrassed I did not notice this when giving my ack before as I even run it on a module but did not take the scope to verify each and every case again.
I applied your patch here and it should still make it into 2.8b4 which is due end of the month.
Cheers
Marcel
Hi Marcel, thank you for your pointer.
You are right the second pulse is generated from the u-boot in nreset_out().
So far so good, but it is always generated also with power-up. I tested it on a eval-board with (Jumper 28 plugged).
I attached a patch to fix the problem:
colibri_imx6: apply nreset_out only if no power-on
Fix the nreset_out() and only pull-down nRESET_OUT reset case
was not a power-on reset.
Cannot use get_imx_reset_cause() because static variable reset_cause
is not initialized, normal done by get_reset_cause() much later.
