T1040 proper reset

[lukaszprzeniosl]

Hello there,

I am working with a board based on the T1040 processor. Currently I am implementing the reset sequence in the companion device for the T1040. I have noticed the following behavior: If I reset the device during u-boot routine, the device starts normally again. However, If I reset the device after the host Linux system is up, the device doesnt turn on anymore. I need to make a complete power recycle.

I tried many different reset schemes from simple PORESET_B asserting to asserting both PORESET_B and HRESET_B + HRESET_B only as well. From the datasheet it seems that there are 2 kinds of resets: soft and hard- I tried both, the behavior is the same. I am connected to the RESET_REQ_B output, but I dont monitor it at the moment.

Am I missing something here? I would appreciate all help.

[jboggs]

It's in the Data Sheet (attached) as opposed to the Refrence Manual.  See Figure 82 on page 181. 

[lukaszprzeniosl]

Thanks for the document John. Indeed there is some "magic" switch... In our design, the TRST_B is directly tied with PORESET_B:

I wonder a bit either this can really mean anything- that they are not disconnected at any point. I think in the end they are both pulled to VDD anyways.

[jboggs]

Lukasz:

I don’t know if this information will be useful to you or not, but I’ll pass it along. The issue I was having was because I was not holding the TRST_B (JTAG Reset) line low during power up. If you look at Figure 82 on page 181 of the T1040 Data Sheet there is a “mystery switch” which seems to be controlled by magic that ties TRST_B to PORESET_B during power up then ties TRST_B to the pull up. As I recall your issue was related to reboot as opposed to power up, but you might want to look at what’s going on with TRST_B during your reboot cycle.

Hope this helps.

[lukaszprzeniosl]

John,

Do you mind refering the datasheet by a number or link it? In the RM I cannot find this figure. Also, In our design the TRST_B line is tied to PORESET_B by an 0R resistor, so it would seem its the way it should be after reading your explanation.

[lukaszprzeniosl]

Hello John,

I will definetly check this tommorow. Thank you for sharing this info.

[jboggs]

Lukasz

Did you ever resolve this issue? I have a T1040 based design configured to read the RCW and boot from a 16 bit NOR flash. Roughly, every 1 out of 100 power cycles the processor won’t boot. All of the power rails appear to sequence properly and the clock is present, but after PORESET_B is released, HRESET_B never goes high, and I see no activity on IFC_CS0_B, so the processor is not attempting to read the RCW. Cycling PORESET_B low and high again will not take the processor out of this state, only another power cycle will resolve the issue. I’m hoping whatever was preventing your system from booting might be the same problem I have, at power up.

[lukaszprzeniosl]

Hello John,

Thanks for answer. We havent dealt with the problem yet. We are now investing the RCW configuration. Will let you know.

[ufedor]

In the described case it is required to doublecheck the reset circuit behaviour using a digital scope.

Asserting PORESET_B for 1ms (in accordance with T1040 Data Sheet) properly initiates power-on reset sequence.

[lukaszprzeniosl]

Hello Ufedor, thank you for answer. I have implemented the 1 ms reset routine, here is the scope view of the PORESET_B line:

The device (T1040) behaves the same way. I am able to reset it while its in the bootloader, but not after the main operating system has started to booting. Do you have any other ideas?

[ufedor]

Please check that the PORESET_B assertion is the same after the main operating system has started to booting.

[lukaszprzeniosl]

Hello Ufedor,

During or after boot, the PORESET_B behavior is the same:

Also, just to make not of it in case its important: I have checked our hardware design for PORESET_N, HRESET_N and RESET_REQ_N circuitry with the reference design from NXP (T1040RDB). Its quite similar.

[ufedor]

Please confirm the PORESET_B is probed at the processor's pin.

[lukaszprzeniosl]

Yes, it is- there is no additional resistance between the processors pin and the probe.

[ufedor]

Excuse me, but it is impossible for the processor to ignore PORESET_B assertion.

Please collect additional information about the processor behaviour after the PORESET_B is asserted in the problem case.

For example - is HRESET_B asserted after that and is the RCW retrieved from the RCW source ROM?

[lukaszprzeniosl]

Ufedor, I think I haven't described the problem clear enough, sorry for that.

After the system is booted, the CPU does notice the reset, since the system is not responsive anymore. The problem is, that the system is not going UP anymore. Its like the reset worked only partially. Before the bootloader boots the system, reset works correctly.

ufedor wrote:

For example - is HRESET_B asserted after that and is the RCW retrieved from the RCW source ROM?

Could you elaborate more here please? As for HRESET_B I will probe it. What is the RCW?

[ufedor]

It is needed to use a multi-channel digital scope to capture reset signals behaviour for normal and problem cases - refer to the QorIQ T1040 Reference Manual, Figure 4-1. Power-on reset sequence.

[lukaszprzeniosl]

Ufedor,

So far I have the scope results for PORESET_B and HRESET_B captured in parallel. The reason for the device not being reset seems obvious now, but the source of the problem is still unknown for me, Please take a look at the 1st scope: I reset the device during bootloader phase:

Keep in mind that the HRESET_B signal is pulled up to VCC by a resistor. The FPGA controlling the CPU has the HRESET_B connected pin configured as High Z for all the time. Nothing inteferes the GRESET_B line.

Now this is what happens when I reset after the system has booted:

Further reading of the HRESET_B pin without power recycle will show that it is low all the time...

What do you think?

[ufedor]

It looks like an RCW readout issue.

[lukaszprzeniosl]

Hi Ufedor,

I still haven't resolved this issue. Do you have any ideas for a procedure I could perform in order to round this down?

[ufedor]

Please ensure that cfg_rcw_src value (signals' levels) is the same for both reset variants.

Sorry, but debugging the custom FPGA remotely is an inconvenient process.