search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.15k stars 6.23k forks source link

test: mimxrt1160_evk/mimxrt1166/cm7 : can't continues flash, always report verifing image fails. #70271

Open hakehuang opened 4 months ago

hakehuang commented 4 months ago

Describe the bug mimxrt1160_evk/mimxrt1166/cm7 : can't continues flash, always report verifing image fails.

Please also mention any information which could help others to understand the problem you're facing:

To Reproduce Steps to reproduce the behavior: use onboard Jlinker debuger west build -b mimxrt1160_evk/mimxrt1166/cm7 samples/hello_world west flash --runner=jlink do above twice you will see below

Booting from FlexSPI1.
  PC = 0x300034B5
  SP = 0x80001080
Clean & invalidate cached CPU registers
AfterResetTarget() end - Took 65.7ms
Downloading file [Z:\temp\zephyr_v3.6.0.bin]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x30000000: 1 range affected (65536 bytes)
J-Link: Flash download: Total: 1.244s (Prepare: 0.260s, Compare: 0.214s, Erase: 0.128s, Program: 0.290s, Verify: 0.213s, Restore: 0.137s)
J-Link: Flash download: Program speed: 220 KB/s

****** Error: Verification failed @ address 0x30000000
Error while programming flash: Verify failed.

Script processing completed.

Traceback (most recent call last):
  File "C:\Users\nxa22633\OneDrive - NXP\github\auto_test\auto_flash.py", line 256, in <module>
    flash(_options.platform, _options.binary, _options.config)
  File "C:\Users\nxa22633\OneDrive - NXP\github\auto_test\auto_flash.py", line 138, in flash
    subprocess.check_call(cmd, **kwargs)
  File "C:\ProgramData\Anaconda3\lib\subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['C:\\Program Files\\SEGGER\\JLink_V796\\JLink.exe', '-USB', '721119608', '-nogui', '1', '-if', 'swd', '-speed', 'auto', '-device', 'MIMXRT1166xxx6_M7', '-CommanderScript', 'runner.jlink']' returned non-zero exit status 1.

git bisect found this is related to HAL upgrading

e4e463af812e61bb5bfb4b1087d48e1dbcd9d8d5 is the first bad commit
commit e4e463af812e61bb5bfb4b1087d48e1dbcd9d8d5
Author: David Leach <david.leach@nxp.com>
Date:   Tue Jan 30 16:22:54 2024 -0600

    west.yml: Update NXP HAL MCUX-SDK to 2.15.000

    Update NXP HAL mcux-sdk to 2.15.000

    Signed-off-by: David Leach <david.leach@nxp.com>

 west.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Expected behavior can continues flashing

Impact Testing

Logs and console output no log output when this happen

Environment (please complete the following information):

danieldegrasse commented 4 months ago

@hakehuang This looks to be related to a change to the flash configuration block with JLink. We have changed the flash configuration block with the MCUX SDK update, and while the new flash configuration block is valid it causes JLink's flashing tooling to throw an error during the verify phase (as the flash device is configured with a new read setting)

I still am able to flash the EVK, but JLink reports an error. If I manually reset the EVK though I can see that the new image has loaded.

hakehuang commented 4 months ago

@hakehuang This looks to be related to a change to the flash configuration block with JLink. We have changed the flash configuration block with the MCUX SDK update, and while the new flash configuration block is valid it causes JLink's flashing tooling to throw an error during the verify phase (as the flash device is configured with a new read setting)

I still am able to flash the EVK, but JLink reports an error. If I manually reset the EVK though I can see that the new image has loaded.

Yes, this is exactly the same with me.

danieldegrasse commented 4 months ago

Yes, this is exactly the same with me.

From more investigation, I suspect this issue is with JLink's interaction with MCUX SDK 2.15. I can reproduce it in SDK applications not using Zephyr, so I think the fix will have to come from our SDK or SEGGER.

dleach02 commented 1 month ago

do we need to push an bug report to Segger?

danieldegrasse commented 1 month ago

From more investigation, I suspect this issue is with JLink's interaction with MCUX SDK 2.15. I can reproduce it in SDK applications not using Zephyr, so I think the fix will have to come from our SDK or SEGGER.

We have- we should leave this issue open, but the bug is being tracked internally

dleach02 commented 3 weeks ago

An issue was submitted to Segger and we are awaiting an update from them. Will lower the priority to low