Trouble Booting Custom T1014 Board: CPU Stuck at 0xfffffffc and JTAG Reset Behavior

[Detrois]

Dear NXP Team,

I am currently working on a customized T1014 Board and have encountered a challenging issue. I am hoping you can provide some guidance or assistance. Here is the situation:

Upon powering up, our CPU fails to reach the U-Boot stage. When I use CodeWarrior with JTAG to attach to the CPU, I find that the CPU halts at address 0xfffffffc. Pressing the Resume button does not allow it to proceed, and a reset does not help either.

We modified the hardware so that the JTAG reset now only sends the HRESET_B signal. This change allowed our CPU to proceed to the U-Boot stage when using JTAG reset. However, when we try to send the HRESET_B signal via an external button, the CPU does not proceed to U-Boot.

Through signal measurement, we observed that when JTAG sends a RESET, not only does the COP_HW_RST# signal get triggered, but signals are also sent on COP_JTAG_TDO, COP_JTAG_TDI, and COP_JTAG_TCK lines. Therefore, we have two questions:

1. Is the timing of sending the HRESET_B signal significant?
2. When JTAG sends a RESET, does it issue any commands to the CPU? If so, what are these commands doing?

Thank you in advance for any insights you can provide.

Best regards

[June_Lu]

We are check SCH-28713 REV C(.brd) now, I will send it to you when I get it.

Thanks for checking T1024RDB development board, any findings please let me know.

If the DCFG_CCSR_RCWSRn registers are set correctly, it will be considered the RCW laoding correctly.

Have you check the PBI command later?  PBI loading will later than RCW loading.

Maybe you could check PBI loading by monitor the flash loading process which the source code is inside with oscilloscope.

Refer the RM, Figure 4-2. Reset Timeline Diagram

[Detrois]

Hi June_Lu,

Thank you for your suggestions. We will measure the signals as you recommended. However, this has brought some additional questions to our attention:

1. We have attempted booting from both NOR Flash and SD Card, but encountered the same issue. Based on my understanding, NOR Flash boot does not require PBI commands because NOR Flash does not need to convert the cache to SRAM to execute the program, whereas the SD card does. Is my understanding correct?
2. We noticed that the DCFG_CCSR_BRR register shows CR0 as 0 when the CPU halts at 0xfffffffc, but after a JTAG reset, CR0 changes to 1.
3. According to the information you provided, the PBI is read after the PLL locks. Is there a way to confirm that the PLL has successfully locked? We have not enabled SerDes.

Thank you for your continued assistance.

Best regards,
Detrois

[June_Lu]

if you have T1024RDB in hand, you could check the waveform with the reference board. But from the waveform, it seems follow the QorIQ T1024 Reference Manual, 4.7.1 Power-on reset sequence.

When power up, from the 4.7.1, the ASLEEP is high impedance, so the voltage would be decided by the initial status, e.g. if there is pull-up, it will high. Because there is no output to drive this signals.

If the sequence is correct, you could test the follow sequence, if the MPU could fetch bootloader.

And you could attach the MPU to confirm the DCFG_CCSR_RCWSRn registers have been set correctly.

But why the POR timing changed from 165 to 882ms, is the design meet the QorIQ T1024, T1014 Data Sheet Table 24.

If you could confirm the MPU could has load bootloader, you could assistant with CWTAP to debug the uboot to see if there is any issue related to SW or SW running.

[Detrois]

Hi June_Lu,

We have a T1024RDB development board, model SCH-28713 REV C. However, on the NXP website, I can only find the brd file for SCH-28624 REV C. Could you please provide the brd file for SCH-28713 REV C so that we can measure the signals on the development board?

We have verified that the DCFG_CCSR_RCWSRn registers are set correctly. I will cross-check the POR timing with the signals measured from the development board based on the information you provided. Lastly, since the PC halts right at the initial position (0xfffffffc), we do not believe it is a software issue.

Thank you again for your assistance.

Best regards,
Detrois

[June_Lu]

Please confirm timing of sending the HRESET_B signal follow QorIQ T1024 Reference Manual, 4.7.1 Power-on reset sequence

For the JTAG control the signals, it would related to sequence of  JTAG debug, it may start to debug the CPU, so the TDO, TDI … would triggered.

Thanks

[Detrois]

Hi June_Lu,

We conducted experiments to vary the timing of the Porset_B trigger, both extending and shortening it, but the results remained unchanged. Please refer to the three images below. In these images, the yellow signal represents 1.8V, the blue signal is Porset_B, the red signal is HRESET_B, and the green signal is ASLEEP.

1. The first image shows the original Porset_B timing, triggered at 250 ms after power-up.
2. The second image shows the trigger timing advanced to 165 ms.
3. The third image shows the trigger timing extended to 882 ms.

Despite these adjustments, there were no changes in the results. Could you please advise if you think our Power-on reset sequence is incorrect? 

Picture 1. Porset_B triggered at 250 ms after power-up.

Picture 2. Porset_B triggered at 165 ms after power-up. 

Picture 3. Porset_B triggered at 882 ms after power-up.

Thank you for your assistance.

Best regards,
Detrois

[Detrois]

Hi June_Lu,

Thank you very much for your prompt response. Following your advice, we have referred to the QorIQ T1024 Reference Manual's Power-on reset sequence to measure the signals. As shown in the attached image:

The yellow signal in the image represents Porset_B, the blue signal is HRESET_B, the pink signal is RESET_REQ_B, and the green signal is ASLEEP. Compared to FIGURE 4-1 in the T1024RM (as shown below):

 

Our HRESET_B appears to be sent out earlier, and the RESET_REQ_B and ASLEEP signals also go high prematurely. This behavior persists even when we disconnect all devices capable of issuing HRESET_B.

Therefore, we would like to ask: what could be causing this phenomenon?

Thank you again for your assistance.

Best regards,
Detrois