rt1170-evk octal flash JLink programming met unexpected PC value

[yf2]

Dear support,

I am using JLink v7.66a with RT-UFL extension provided by @kerryzhou in this ticket on Linux to program the led-blinky demo to octal flash of RT1170-EVK device.

This setup worked well in the past few days but somehow today I encountered error saying:

ERROR: PC of target system has unexpected value after preparing target. (PC = 0x00000000)

Detailed logs are attached for review.

The same error happens to JLink v.66a on Windows as well.

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

  You mean, when you meet issues, it always can use the JLINK connect it do the erase and program?

  Or sometimes is OK, sometimes is failed?

  You can try the windows method again, please note, RT-UFL device use my modified firmware, whether that also can't work?

   If yes, I highly suggest you test the serial download mode with the MCUBootUtility, whether that tool can connect it with the USB HID without the debugger, just make sure your board still working.

Best Regards,

Kerry

[yf2]

@kerryzhou 

Thanks for your prompt reply! 

To answer your questions:

>>> Or sometimes is OK, sometimes is failed?

It worked on Monday and Tue, but today the unexpected PC value error appears somehow. I don't know why as I am not aware that I changed anything. I just did some test with programs built with "flexspi_nor_sdram_debug" type but they were not successful, I am unsure if they can cause the device enter this strange state...

>>> You can try the windows method again, please note, RT-UFL device use my modified firmware, whether that also can't work?

Yes i am using your modified .flm drivers on both Windows and Linux with JLink v7.66a, you can confirm it from logs that your device definition is used.

>>> test the serial download mode with the MCUBootUtility

I don't know how to use MCUBootUtility tool yet. But I downloaded blhost 2.6.7 tool and can use it to do simple access to the target view USB1 port. I can issue "reset" and "get-property" commands via blhost tool to the target with SW1 set as 0000. Is this enough to show that the target is still okay?  I also downloaded NXP-MCUBootUtility.exe tool, I guess this is what you mean by MCUBootUtility, right?

Regards,

yf2

[yf2]

@kerryzhou

It seems that my board's situation is similar to this1 and this2 tickets. However I don't know how they changed the reset method. Would you please give it a look?

On the other hand, is it possible for me to reset my JLink connection somehow so that I can program octal flash stably? I seemed have MCUBootUtility access but I don't know how it can be used to reset my board to a known state.

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

   If the downloaded code is abnormal for booting, it will cause the debugger debug issues.

  That's why I let you use the MCUBootutility do a mass erase at first, that will help you back to the normal states, about reset, just power off and power on again.

Best Regards,

kerry

[kerryzhou]

Hi @yf2 ,

  Talk about the MCUBootUtility test in the serial download mode:

1. board connection:

2. tool settings

3. connect

After connecting, you can write mass erase, then test the debug again.

Best Regards,

Kerry

[yf2]

@kerryzhou 

I tried MCUBootUtility as your screen shots.

1. Power off device, disconnect debug USB cable. Set SW1 as 0001 to enter Serial downloader mode; Connect USB1 to PC;
2. Power on the device; Start MCUBootUtility.exe and select Macronix_MX25UM51345G as FlexSPI NOR device type;
3. Choose USB-HID connection type and confirm VID/PID is found.
4. Press "Connect to Xxx" button in MCUBootUtility, the light icon blinked and finally became blue; USB VID/PID also blinked and finally shows 0x15a2 and 0x0073
5. Select "boot device memory" tab and check start/offset is 0, length 0x2000. Then click "mass erase".
6. The erase process took long time (2.5min) and the VID/PID changes to "not found"... but finally it changes back to 0x15a2 and 0x0073
7. Power off and adjust SW1 as 0010, disconnect USB1 to quit serial downloader mode.

Here I attached a copy of MCUBootUtility log file for your review.

However, my JLink still reports unexpected PC value error. It seems that the Octal flash is still not successfully erased?

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

   I mean, the log like this:

You can see all the results, it is a success, it means are all OK.

About the erase, then you can readout the memory to check it:

You can see, all are 0XFF, it is erased.

About the JLINK reports unexpected PC value error, please give me a picture about it, then I will also check it on my board.

At least, my board still working now.

Best Regards,

Kerry

[yf2]

Kerry,

Thanks for sharing the "read" button function, I confirmed I can see only 0xffff after "erase all" in MCUBootUtility.

Is it possible to flash my .elf file from MCUBootUtility? please teach how to do it.

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

  Yes, of course!

  You can test the MCUBootUtility attached .elf at first, it is the led_blinky code, after it works, then you can try your own elf, normally, you need to generate the .elf without the FCB, as the tool will help you to generate it.

Tool attached app path is:

NXP-MCUBootUtility-3.5.0\apps\NXP_X-IMXRT1170-VAL_Rev.A2\cm7

Best Regards,

Kerry

[yf2]

Kerry,

>>> normally, you need to generate the .elf without the FCB, as the tool will help you to generate it.

What does this mean for CMake users? I guess that FCB is provided by "xip board driver component", so I should not include that component when using "flexspi_nor_debug" build type?

BTW, I tried to program the demo apps "iled_blinky_30000a00_iar.elf" as your screenshot with serial downloader, it works smoothly and no error shows. However, when I tried to program my ARMGCC build of "iled_blinky_cm7.elf", it showed an error saying "Can't recoginse/convert the format of the image file" even though i selected to "out(.elf) from GCC ARM" option.

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

   So, the MCUBootUtility tool attached: led_blinky_0x3000a000_iar.elf(NXP-MCUBootUtility-3.5.0\apps\NXP_MIMXRT1170-EVK_Rev.A\cm7), totally download and boot works OK, right?

   As this code is just put code from 0X3000A000, as you know, from 0X30000000 is the FCB, then from 0X30001000 is the IVT+BD+DCD file,  if you check the .srec file, which contains the address, it will be more easy to check the detailed data:

So in your project, when you generate the code, you can define :

XIP_BOOT_HEADER_ENABLE=0

Then the memory put from 0X3000A000. then the tool will help you add the FCB and IVT.

In your CMake project, can you configure the defined symbols or not? and the memory address?

I mainly use the IDE like MCUXpresso + IAR+MDK to build the project.

 From your mentioned error:  "Can't recoginse/convert the format of the image file" 

It mainly caused by the generated image is not correct, still contains FCB+IVT directly.

MCUbootUtility tool is special, but the JLINK download should can download your complete generated firmware directly. as your generated code should contains FCB+iVT, which is needed by the JLINK directly.

Talk back to your issues, if the MCUBootutility can download the code works OK with it's tool attached file, your board should still works OK.

Now, can you try the JLINK download again, I think you can try the windows method which I told you with my modified firmware, until now, my board still working, no PC error in windows system with RT-UFL. No mtatter JFlash directly or JLINK+MCUXpresso IDE.

Best Regards,

Kerry

[yf2]

@kerryzhou 

>>> For MCUBootUtility programming:

Thanks for teaching the reason of program format error. I tweaked CMakeLists.txt by removing XIP dependencies then the output .elf program can be flashed by MCUBootUtility tool successfully. 

>>> For JLink programming:

I tested more and found that when "dcd.c" dependency is included in my program built with  MIMXRT1176xxxxx_cm7_flexspi_nor.ld, it will have the "unpexected PC value error" or other boot issues. When "dcd.c" dependency is removed, there is no such error.

I don't know why "dcd.c" makes such differences.

Regards,

yf2

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

  Seems you lack the log!

  Do you use the JFLASH with your JLINK plus, in my memory, I have shared the related picture to you in another post, which I share you the modified RT-UFL firmware.

best Regards,

Kerry

[yf2]

@kerryzhou 

>>> seems you lack the log!

My bad. Here I attached a copy of JLinkGDBServer logs of the unexpected PC value error for your review.

As I can't use JFlash with JLink OB here, I am always using JLinkGDBServer for JLink flashing from gdb here.

[kerryzhou · Accepted solution]

Hi @yf2 ,

   Sorry, as each day, we process a lot of different cases, so I little lost in your previous situation.

  So, I checked your previous working situation, whether that works OK with JLINK command or not, which I told you in this post:

https://community.nxp.com/t5/i-MX-RT/How-to-program-rt1170-evk-octal-flash-with-JLink/m-p/1487099#M2...

 I also share the app image, if you don't use the JLINKGDB, just use the JLINK command loadfile, whether that works OK or not?

  I checked your JLINK GDB log, seems you already find the ARM core, but then it meet issues. Maybe related to the JLINK GDB.

  Normally, when we use the IDE, eg. MCUXpresso IDE, it is using:

JLinkGDBServerCL.exe

  You can see the above link, my JLinkGDBServerCL.exe log also works with IDE.

Best Regards,

Kerry

[yf2]

@kerryzhou 

Thanks for all the help.

This issue was gone after excluding the "dcd.c" from my program. I don't know the reason why this made the difference.

But to save your time, I closed this ticket for now.

Regards,

yf2

[kerryzhou]

Hi @yf2 ,

  Thanks for your understanding.

 From your description, it is related to the dcd.c, which is used for the SDRAM chip SEMC interface configuration. Then, you need to make sure the IVT area also add the DCD address, it is related to the customer application code.

  I think you can test the SDK hello_world, that also contains the SDRAM, if that also works, then it is your customer code issues.

  Any new issues, welcome to create the new case.

Best Regards,

Kerry