Hi @raghulshanmuganathan-sigm ,
First, I apologize for not being clearer about the interrupt vector table. This device uses an Image Vector Table (IVT), that points to the application image, which then also has an interrupt vector table. I went through the steps to execute the app using blhost, so I will explain this more below.
To provide you these detailed steps and knowing that you are using Zephyr, I built the Zephyr blinky application for the MIMXRT1060-EVKB board using Zephyr v3.2. But by doing these steps, I realized the default application images built by Zephyr (and MCUXpresso SDK examples) will not boot with the blhost execute/call commands. That is because by default these applications have the linker place the data in external SDRAM, including the stack. The applications also include the Device Configuration Data (DCD) in the application image. When the ROM bootloader boots from flash, it finds the DCD and configures the hardware according to that DCD, which initializes the clocks and SEMC for the external SDRAM. But if the ROM bootloader boots in Serial Download mode instead, and blhost is used to launch the app, the bootloader does not read the DCD, and the SDRAM is not configured before the application executes.
To workaround this, I modified the Zephyr devicetree to place data in internal SRAM instead of SDRAM, specifically in the Data Tightly-Coupled Memory (DTCM). With this change, the DCD is not needed to launch the application, and blhost can launch it. To make this change for this EVK, I modifed the file \zephyr\boards\arm\mimxrt1060_evk\mimxrt1060_evk.dts with the line below:
zephyr,sram = &dtcm; # was &sdram0
Then I built the Zephyr application with this command below. Attached is the generated binary file.
west build -b mimxrt1060_evkb samples\basic\blinky --pristine
I then used sdphost and blhost commands same as you to load the flashloader, configure the memory, and read the memory. As you said, the Image Vector Table is located at address 0x60001000 in the flash. Here are the first two words in this blinky IVT:
>blhost.exe -u 0x15a2,0x0073 -- read-memory 0x60001000 8
Inject command 'read-memory'
Successful response to command 'read-memory'
d1 00 20 41 00 20 00 60
(1/1)100% Completed!
Successful generic response to command 'read-memory'
Response status = 0 (0x0) Success.
Response word 1 = 8 (0x8)
Read 8 of 8 bytes.
The second word in this IVT is the entry address that points to the address of the application. For my blinky app, the blhost read command shows the entry address is 0x60002000.

I do another read command at the entry address to read the interrupt vector table of the application:
>blhost.exe -u 0x15a2,0x0073 -- read-memory 0x60002000 8
Inject command 'read-memory'
Successful response to command 'read-memory'
00 10 00 20 91 33 00 60
(1/1)100% Completed!
Successful generic response to command 'read-memory'
Response status = 0 (0x0) Success.
Response word 1 = 8 (0x8)
Read 8 of 8 bytes.
The first word in the vector table is the initial stack pointer (SP), shown here as 0x20001000. Note that after my devicetree change, this SP is now in DTCM. That is important for the next steps. Originally this SP was in SDRAM at base address 0x80000000, and blhost could not launch the application.
The second word in the vector table 0x60003391 is the reset vector. With these two addresses, I can now use blhost to launch the app:
>blhost.exe -u 0x15a2,0x0073 -- execute 0x60003391 0 0x20001000
Inject command 'execute'
Successful generic response to command 'execute'
Response status = 0 (0x0) Success.
Note in the above execute command, the 3rd argument is the stack pointer. I also tested this command as "execute 0x60003391 0 0" and it does work in this case. But I suspect that may depend on the application setting the SP before using it.
I can also launch the app with the blhost call command like below. When I use this command, you can see blhost reports an error because the app does not return to the flashloader. But the app does execute on my EVK.
>blhost.exe -u 0x15a2,0x0073 -- call 0x60003391 0
Inject command 'call'
sendCommandGetResponse.readPacket error 5.
Response status = 10004 (0x2714) No response packet from target device.
So now you can try these steps. Your last post shows your entry address in the Image Vector Table is 0x6001A951, which seems like an unusual address for the application. Can you read the flash at this address 0x6001A951 and share the results? If needed, you can also use the .MAP file generated by the linker to confirm the reset entry address for the app.
Let us know if this works for you