LS1043A errors when trying to connect with JTAG

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LS1043A errors when trying to connect with JTAG

1,922 Views
ss-nxp
Contributor I

We are bringing up a custom board based on the LS1043AXE8QQB and all JTAG operations have started returning errors, preventing further progress. The symptoms are very similar to https://community.nxp.com/t5/Layerscape/LS1012A-QSPI-Flashing-Problem-on-Custom-Board/m-p/1052911

When trying to connect from CodeWarrior, the flash programmer fails to launch, even with USE_SAFE_RCW. When we run diagnostics we see errors like IR Scan failing:

scotsalmon_3-1612487470120.png

Sometimes it gets past there and shows:

scotsalmon_4-1612487497055.png

We have reduced the JTAG speed (from 16000 to 10000 and even 1000) with no apparent effect. We also tried swapping to a different TAP and JTAG cable. This TAP/cable work on other devices (and were working on this device earlier).

When we try to flash the device from gdb instead of CodeWarrior, we see:

(gdb) Starting flash programmer services...
Starting local server...
Successfully started gdb server 127.0.0.1:45000
Set gdb remote timeout to 7200
Connecting to target...
Using LS1043A SoC
Using CWTAP 192.168.5.116
Using jtag speed 16000
Connecting to probe...
connected successfully
Successfully connected to probe
Initializing target...
Running init script c:\freescale\cw4net_v2020.06\cw_armv8\armv8\gdb_extensions\flash\scripts/../../../../Config/boards/LS1043A_RDB_init.py
RCW error encountered. In order to diagnose the error temporarily change the board configuration switches to ignore the assertion of the RESET_REQ_B signal. Please refer to board reference manual in order to locate the appropriate switch that controls this behavior.
Error: fail to initialize target

Our design disconnects RESET_REQ_B from PORESET_B anyway, so we are already ignoring that. If we modify the LS1043A_RDB_init.py script referenced there to USE_SAFE_RCW, we get the same error we see in CodeWarrior's flash programmer, which is:

[Failed to write memory at address 0x2016002c on core CortexA53#0.
Core CortexA53#0 not found on the JTAG chain. Please verify that the Reset Configuration Word is correct, or enable RCW Override in the initialization file.]

Our design does not have an easy way to change cfg_rcw_src to 0 – in the past we've always accomplished the same effect by using USE_SAFE_RCW in the CodeWarrior Target Initialization File, but that is no longer working.

We had been using the flash programmer without issues on this device successfully many times before we got into this state. The noteworthy change leading up to this issue is that I flashed a bl2 image built for the LS1043AQDS instead of the LS1043ARDB-based ones we had been using before. This is a custom board but its configuration is based largely on the RDB, except for the boot device. I tried the QDS bl2 because our design is shared with a LS1046A design which uses QSPI boot, and we noticed in the Layerscape SDK User Guide (rev 20.12) table 27 that the LS1043ARDB does not support QSPI boot. We also see that there is no "qspiboot" variant for the RCW for the LS1043ARDB in source: https://source.codeaurora.org/external/qoriq/qoriq-components/rcw/tree/ls1043ardb/RR_FQPP_1455 but we do see qspiboot variants in the LS1043AQDS source: https://source.codeaurora.org/external/qoriq/qoriq-components/rcw/tree/ls1043aqds/RR_SSPH_3358

Questions:

  • Is there something about the QDS RCW that would explain why flashing that bl2 put this device into such a bad state?
  • Do you have ideas/suggestions we haven't tried to get it out of the bad state?
  • Does the LS1043A work with QSPI boot? In other words if we got past this RCW/JTAG issue, would we still be stuck because the 1043 can't boot QSPI anyway?
0 Kudos
6 Replies

1,901 Views
yipingwang
NXP TechSupport
NXP TechSupport

1. The RCW in QSPI flash is not suitable for your custom board.

2. Please refer to the following to modify CW initialization file.

In order to connect to a board with a broken RCW, set the following variable to True
# Override RCW using a safe hard-coded RCW option
USE_SAFE_RCW = True

# LS1043A RDB-PD uses a new NAND flash device
BOARD_REV_PD = True

# Specify the current boot source.
# 0 - NOR Flash
# 1 - NAND Flash
# 2 - Other device (Hardcoded RCW, SD, etc.)
BOOT_CHIP_SELECT = 2

# Because the QSPI controller cannot work at the same time with the
# IFC controller, this variable will enable QSPI boot and initialize
# only the QSPI and disable the IFC;
QSPI_BOOT = 1

3. LS1043A supports QSPI boot.

0 Kudos

1,895 Views
ss-nxp
Contributor I

We tested with your suggested settings and are seeing the same errors reported above. The flash programmer errors out on launch, and the JTAG diagnostic fails the "bit error stress pattern".

Note that your suggested USE_SAFE_RCW and QSPI_BOOT setting matched what we were already using.

From what I can tell, BOARD_REV_PD does not apply to us, but I applied your suggestion anyway. It controls what NAND device is used and how DDR is initialized, right? But the NAND initialization is skipped since QSPI_BOOT is 1, and we are using our board's custom DDR configuration (which was working well enough to program the flash until I applied the QDS firmware).

I changed BOOT_CHIP_SELECT from 0 to 2 per your recommendation but it does not have any apparent effect on the results.

It is good to know in your answer to question 3 that QSPI boot is supported on the 1043. Now we just need to get JTAG working again...

0 Kudos

1,888 Views
yipingwang
NXP TechSupport
NXP TechSupport

Does your target board support other boot option except QSPI boot?

If yes, please configure your target board boot from other boot option to avoid the improper firmware in QSPI flash executing before connecting to CodeWarrior.

Please don't configure your target board in the state booting from QSPI flash to check whether it is possible to execute ccs::config_chain successfully.

0 Kudos

1,879 Views
ss-nxp
Contributor I

Unfortunately our cfg_rcw_src pins are hardwired to QSPI (001000100).

I've tried changing the QSPI_BOOT and BOOT_CHIP_SELECT values in the target initialization file in CodeWarrior, but it didn't have any effect, we see the same errors reported above. From the errors we're seeing from the diagnostic tool, it seems like we're probably not even getting far enough for the settings in that Python file to be used.

Is there any other way to change the boot option?

0 Kudos

1,858 Views
yipingwang
NXP TechSupport
NXP TechSupport

It is possible to connect an empty QSPI flash on your target board?

Because improper firmware running in QSPI flash, which causes configuring the target board in an invalid status, the first step ccs::config_chain failed, no chance to run the Python script in CodeWarrior at all.

1,852 Views
ss-nxp
Contributor I

It's good to know that might work, but unfortunately it's also not an option for us. The flash connected to QSPI is a BGA package, and removing or reprogramming it would be harder than the previous idea of reworking the board to set cfg_rcw_src.

Edit: I just realized we might be able to toggle the flash's chip select to a flash bank we've never used, long enough to get past this issue, without too much trouble. This might be our best option so far.

0 Kudos