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]

Please create a new case to further support.

Thanks

[Detrois]

Sorry, did you mean to create another topic in the Nxp community?

[June_Lu]

Thanks for the information.

Is the "u-boot-with-spl-pbl.bin" generated by the customer?

In fact, I found the end command at offset 0x2A8F0.

Maybe check the PBI command for this bin.

The HRESET_B is controlled by the CPLD on the T1024RDB partly.

If the HRESET is not asserted when the PORESET asserted, that all devices controlled by the HRESET_B would be not in the reset status, please check if it is any risk.

But for the MPU boot, should confirm these devices will not affect the boot.

[Detrois]

Hi June_Lu,

Apologies for the late reply. The "u-boot-with-spl-pbl.bin" file was we generated using SDKV2.0. To verify whether the PBI commands were received, we modified the PBI commands and used JTAG to attach and check if they took effect. The results showed that the corresponding registers were written with the correct values. Do you have any further suggestions regarding the PBI?

Additionally, our T1014 board does not have a CPLD and is not currently connected to any device that can send HRESET_B. We will now try adjusting the power-on sequence to be similar to that of the T1024 development board. If we have any new findings, we will let you know. Please feel free to share any thoughts or suggestions you might have. Thank you again for all your help.

Best regards,
Detrois

[June_Lu]

Compare the 2 bin file, it seems "u-boot-with-spl-pbl.bin" lost "End command" "08138040".

Please confirm this.

And the "nor_current_rcw.bin" no PBI command.

[Detrois]

Hi June_Lu,

Thank you for the information. We have reviewed the PBI commands again and identified the following issues. Let’s discuss the "u-boot-with-spl-pbl.bin" built from SDK 2.0 and the "nor_current_rcw.bin" from the development board separately:

For "u-boot-with-spl-pbl.bin":

1. We found the code to add the end command in the SDK, but it doesn't seem to be effective.
2. When using JTAG to attach the T1014 board, we can confirm that the PBI commands work even without the end command.
3. "u-boot-with-spl-pbl.bin" runs smoothly on the T1024 development board without any issues.

For "nor_current_rcw.bin":

1. It indeed does not contain PBI commands, but is there any need for PBI commands when booting from NOR flash?
2. Similarly, it runs smoothly on the T1024 development board. In fact, it originally came with the development board.

Thank you again for your assistance.

Best regards,
Detrois

[June_Lu]

I have send the LAY-28713.brd to your email.

Please kindly let me know if you receive it.

Please kindly just send the RCW.bin instead of all.bin to check the PBI.

In fact, you just test CS(e.g. NOR) follow the Reset Timeline Diagram,

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

The boot sequence will be distinct difference between the RCW loading and PBI time and later. As the RCW frequency is SYSCLK/4, and later is platform clock/8, afer the PBI there is platform clock set by the customer.

You could test the signals between the T1024RDB and customer board.

But I think the sequence before the RCW is correct.

[Detrois]

Hi June_Lu,

Thank you for your help. I have received the file.

Attached is the RCW we dumped from the T1024 development board's NOR flash. This is the same RCW we programmed into the T1014 customer board's NOR flash. Please take a look.

We will use the method you suggested to monitor whether the PBI has been read. This will take some time, but I will update you with the results as soon as possible.

Thank you again for your assistance.

Best regards,
Detrois

[Detrois]

Hi June_Lu,

Based on the brd file you provided, we measured the power-on sequence on the T1024 development board. To observe the CPLD's behavior, we removed resistors R94, R96, and R98, as shown in Image 1. The T1024 still operates normally after removing these resistors.

Images 2 and 3 show the measurement results. The yellow signal is the 1.8V voltage, the blue signal is Porset_B, the red signal is HRESET_B, and the green signal is ASLEEP. In Image 2, you can see the entire power-on sequence, which looks very similar to our T1014. The difference is that HRESET_B and Porset_B pull high together on the T1024. Image 3 shows a zoomed-in view of the initial power-on signals, where both HRESET_B and Porset_B pull high, while in the T1014, only HRESET_B pulls high.

In summary, the differences between the T1014 and T1024 are:

1. The timing of the HRESET_B and Porset_B pull high is inconsistent.
2. At the initial power-on moment, only HRESET_B pulls high.

Do you think it is necessary to adjust the power-on sequence of the T1014?

Image 1 . The resistors that we removed.

Image 2 . The power-on sequence on the T1024 development board.

Image 3 Zoomed-in view of the initial power-on signals.

Thank you for your assistance.

Best regards,
Detrois

[June_Lu]

Please check customer RCW.bin, check the first-part4 bytes of the last 8 bytes, do they follow RM, page 1358, Table 26-2. Required format of data structure used by PBL.

If the 4 bytes correct, please check the commands above to see if there is any PBI after the RCW data. That the RCW.bin has been programed into the flash.

For the CFG_CCSR_BRR register shows CR0 as 0, how do you set RCW [BOOT_HO]? check the RCW.bin.

There is a pin CLK_OUT, but I think you need to set the register CLKPCSR.

Please follow, RM, page 216, 4.7.7.3 CLK_OUT configuration

[Detrois]

Hi June_Lu,

I have checked the first eight bytes of the RCW, and they are AA55AA55, which is correct. There is indeed data between the RCW and UBOOT, but I cannot confirm if it is PBI commands. Additionally, the RCW[BOOT_HO] is set to 0.

The RCW.bin files we are testing are generated from the NXP-provided SDKv2.0, and they have been tested successfully on the T1024 development board. I have attached the RCW.bin file we used for validation.

Thank you again for your assistance.

Best regards,
Detrois

[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