Custom RT1064 can not be flashed with Jlink on Zephyr #74089
-
|
We have a custom board RT1064 which we are not able to flash with jlink on Zephyr v3.6.0. At the end we get the following error: Any help would be appreciated :) |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
Hi @mariopaja , Also, is the FCB and IVT required to boot from the FlexSPI flash included in your Zephyr image? You can view these boot structures are the start of the image in the two binary files and see if they are different. If they are missing from your Zephyr image, then perhaps your custom board is not including them. Another thought, since you are booting from the integrated flash on the FlexSPI2, this is the same as our EVK. You could try building a Zephyr app for the mimxrt1064_evk board, and try loading that on your board. I expect the ROM would be able to boot it up, even if the app does not run correctly due to board differences. So I would expect the Jlink to be able to flash that image successfully to your board. If so, that would also point to a difference with your custom board config. Let us know what you find. |
Beta Was this translation helpful? Give feedback.
-
|
@DerekSnell Thank you for your tips and sorry for my late reply, only now I could come back into this topic.
I could not flash the zephyr image with the MCUXpresso GUI Flash, ar at least I had the same results as before :/
Flashing our custom board with the mimxrt1064_evk image did not fix the issue :/
Left - Bare metal
On MCUXpresso on sdram_ini_dcd i found several differences compared to the mimxrt1064 and I already changed it to a local file. However, it did not change the behaviour |
Beta Was this translation helpful? Give feedback.
-
|
Hi @mariopaja , And your flash dumps show the flash is programmed with the Zephyr images. I suspect the device is booting, but runs into an issue early in the startup code, and faults or runs away. Can you use a debugger and halt in the reset entry function? That would confirm it is booting. And then you can step through the code and see how far it gets. Let us know what you find. |
Beta Was this translation helpful? Give feedback.
-
|
@DerekSnell Thank you it seems the issue is related to the SDRAM!
Yes the board has SDRAM and yes it is the same as the evk.
I just did it and the mcu booted without any problem. I also tested the SDRAM with the bare metal SEMC SDRAM Example. The 32-bit and 16-bit test fail. Only the 8bit test passed :/ However when I disable EMC_39 only the 32bit test fails. |
Beta Was this translation helpful? Give feedback.
-
|
@DerekSnell The SDRAM itself works but it seems like it takes too long for the SDRAM to become available for write/read 2 consecutive 32bit write/read - bare metal sample A printout of write/read data:
|
Beta Was this translation helpful? Give feedback.
Hi @mariopaja ,
The baremetal image that works does not include the DCD, which configures for SDRAM. Does your board have SDRAM? If so, is it the same used on the EVK? The default Zephyr image will place data in SDRAM, and try to access it early in the startup code. I would move the data
zephyr,sramnode to DTCM to rule out issues with the SDRAM.And your flash dumps show the flash is programmed with the Zephyr images. I suspect the device is booting, but runs into an issue early in the startup code, and faults or runs away. Can you use a debugger and halt in the reset entry function? That would confirm it is booting. And then you can step through the code and see how far it gets.
Let us …