iMX RT1062 JTAG not working

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

iMX RT1062 JTAG not working

Jump to solution
1,982 Views
DavidVos
Contributor II

Hi,

I am currently working with an iMX RT1062 OEM  board trying to get JTAG to work instead of SWD as I want to daisy chain some devices. I found this thread: https://community.nxp.com/t5/i-MX-RT/RT1062-JTAG-Debugging/m-p/946048 basically explaining that an efuse needed to be burned to put the board in JTAG mode. I then used the ocotp code in de MCUxpresso SDK to burn said efuse. Used code:

/*
* Copyright 2019 NXP
* All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/

/*******************************************************************************
* Includes
******************************************************************************/
#include "board.h"
#include "fsl_ocotp.h"
#include "fsl_debug_console.h"

#include "pin_mux.h"
#include "clock_config.h"
/*******************************************************************************
* Definitions
******************************************************************************/
#define EXAMPLE_OCOTP_FREQ_HZ (CLOCK_GetFreq(kCLOCK_IpgClk))
/* NOTE: enable this feature will write data to the fuse map, and this operation is
* irreversible. Please refer to the referance manual before using the read/write
* function, and calling the write API cautiously.
*/
#define EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE 1U

#if defined(EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE) && (EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE)
/* 0x22 is address of MAC0 fuse map. */
#define EXAMPLE_OCOTP_FUSE_MAP_ADDRESS 0x460
#define EXAMPLE_OCOTP_FUSE_WRITE_VALUE (1<<18)
#endif

/*******************************************************************************
* Prototypes
******************************************************************************/

/*******************************************************************************
* Variables
******************************************************************************/

/*******************************************************************************
* Code
******************************************************************************/
/*!
* @brief OCOTP example.
*
* @details Just prints version of driver by using OCOTP API.
*/

int main(void)
{
uint32_t version;

/* Init hardware*/
BOARD_ConfigMPU();
BOARD_InitPins();
BOARD_BootClockRUN();
BOARD_InitDebugConsole();

PRINTF("OCOTP Peripheral Driver Example\r\n\r\n");

OCOTP_Init(OCOTP, EXAMPLE_OCOTP_FREQ_HZ);

/* Get the OCOTP controller version. */
version = OCOTP_GetVersion(OCOTP);
PRINTF("OCOTP controller version: 0x%08X\r\n\r\n", version);

/* Example code to write a MAC value the MAC0 register (0x22) and reload the shasdow register to read it back. */
#if defined(EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE) && (EXAMPLE_OCOTP_SHADOW_REGISTER_READ_WRITE_ENABLE)
/* Read the LOCK register for checking the MAC_ADDR status. 0x00 stands for unlocking status. */
if (0x00U == (OCOTP_LOCK_MAC_ADDR_MASK & OCOTP_ReadFuseShadowRegister(OCOTP, 0x00)))
{
PRINTF("The origin value of fuse address 0x%02X is 0x%08X\r\n", EXAMPLE_OCOTP_FUSE_MAP_ADDRESS,
OCOTP_ReadFuseShadowRegister(OCOTP, EXAMPLE_OCOTP_FUSE_MAP_ADDRESS));

if (kStatus_Success ==
OCOTP_WriteFuseShadowRegister(OCOTP, EXAMPLE_OCOTP_FUSE_MAP_ADDRESS, EXAMPLE_OCOTP_FUSE_WRITE_VALUE))
{
PRINTF("OCOTP Write operation success!\r\n");
PRINTF("The new value is 0x%08X\r\n", OCOTP_ReadFuseShadowRegister(OCOTP, EXAMPLE_OCOTP_FUSE_MAP_ADDRESS));
}
else
{
PRINTF("OCOTP write operation failed. Access deny!\r\n");
}
}
#endif

while (1)
{
}
}

 After burning the efuse nothing seemed to be changed however. This is the output when running JLINK commander:

Connecting to target via JTAG
InitTarget() start
InitTarget()
_TargetHalt: CPU halted
InitTarget() end
Could not measure total IR len. TDO is constant high.
InitTarget() start
InitTarget()
_TargetHalt: CPU halted
InitTarget() end
Could not measure total IR len. TDO is constant high.
InitTarget() start
InitTarget()
_TargetHalt: CPU halted
InitTarget() end
TotalIRLen = ?, IRPrint = 0x..000000000000001FFFFFFFFF
InitTarget() start
InitTarget()
_TargetHalt: CPU halted
InitTarget() end
Could not measure total IR len. TDO is constant high.
Cannot connect to target.

Connecting and flashing with SWD still works fine, which should not be the correct behaviour as burning the efuse should put the board in JTAG mode instead of SWD mode.

thanks for your time.

Tags (2)
0 Kudos
1 Solution
1,902 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello David, 

I'm glad to hear that you were able to burn the fuse! There isn't any other fuse that has to be burned in order for JTAG to work properly. I don't know if the OEM board that you are using requires some hardware changes to work with JTAG instead of SWD. For example, in the case of our RT1060-EVK, since the RT by default comes with SWD if you want to use JTAG instead of SWD there are some hardware changes that you need to implement in the board besides burning the fuse. 

Regards,

Victor 

View solution in original post

0 Kudos
4 Replies
1,950 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello David, 

With the code that you are running, you are actually writing to the shadow registers, this doesn't burn the fuse. To properly burn the fuse I would recommend you use the MCUBootUtility which you can download from the following link.  

Section 4.2 of the documentation in the GitHub page explains how to burn the fuses with this tool. Keep in mind that to burn the fuse your board has to be in serial downloader mode and you will need to communicate with the RT either through USB or UART. 

 

Have a great day,

Victor

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct"button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-------------------------------------------------------------------------------

0 Kudos
1,924 Views
DavidVos
Contributor II

@victorjimenez 

Thanks a lot for your post. I connected with the MCUBootUtility and burned the correct efuse (0x460[19]).

The good news is that SWD no longer works which is the expected behaviour.

The bad news is that JTAG still does not work which is not the expected behaviour.

The readout from running jlink commander is: 

Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: MIMXRT1062XXX6A
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
T) cJTAG
TIF>
Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "MIMXRT1062XXX6A" selected.


Connecting to target via JTAG
InitTarget() start
InitTarget()
Connect Under Reset
Connect Under Reset
InitTarget() end
InitTarget() start
InitTarget()
Connect Under Reset
Connect Under Reset
InitTarget() end
InitTarget() start
InitTarget()
Connect Under Reset
Connect Under Reset
InitTarget() end
InitTarget() start
InitTarget()
Connect Under Reset
Connect Under Reset
InitTarget() end

Is there perhaps another efuse that needs to be burned or a jumper that needs to be connected?

Thank you for your time.

regards,

David

0 Kudos
1,903 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello David, 

I'm glad to hear that you were able to burn the fuse! There isn't any other fuse that has to be burned in order for JTAG to work properly. I don't know if the OEM board that you are using requires some hardware changes to work with JTAG instead of SWD. For example, in the case of our RT1060-EVK, since the RT by default comes with SWD if you want to use JTAG instead of SWD there are some hardware changes that you need to implement in the board besides burning the fuse. 

Regards,

Victor 

0 Kudos
1,886 Views
DavidVos
Contributor II

Hi Victor,

You were correct in that some hardware changes need to be made. It turned out that the TDI and TDO pin were shared by the ethernet controller and these needed to be pulled high and low respectively. 

Thank you for your help regarding this matter, your time is greatly appreciated.

Regards,

David