Trying to use j-link debugger for QSPI Flash with i.MXRT 1052

[ap213]

Hello dear Forum,

I'm currently working on a project where I want to use an i.MXRT 1052 as a graphics processor for a 800x480 LCD display using the litlevgl library. Our custom board has a IS25LP064A-JBLE QSPI Flash memory and also a IS42S16160G-7BLI SDRAM memory. As a starting point I'm using MCUXpresso IDE v11.4.1 with the evkbimxrt1050_littlevgl_guider project provided by the SDK 2.10.0. I've addapted the evkbimxrt1050_flexspi_nor_config.c for our flash so that we can use XIP and successfully debugged the project using j-link. So far so good. I also have a EVKA 1052 development board where I've made the necessary hardware changes which are required to use the QSPI Flash for XIP. The example also ran in debug with j-link. So I have made sure both boards (ours and the evka development board) can be debugged successfully with the exact same source code. 

Here's where my problems start. I've developed a more complex UI interface (a bunch of buttons and containers, still using the littlevgl library) than the one provided in the original example. I'm still able to debug it on the evka dev board but on our board something peculior happens: The debug session starts and stops at the main break point. When I press continue the screen shows the UI for a second and then turns black. The IDE doesn't allow me to pause the debugger and eventually it shows me in the disassembly: Failed to execute MI command: -data-disassemble -s 3735928558 -e 3735928591 -- 3 Error message from debugger back end: Cannost access memory at address 0xdeadbeef. If I scrow up and down the disassembly window it just shows all addresses as nreachable 0xdeadbeee, 0xdeadbeec, etc. Another problem is that this behaviour is not stable. What I mean is that sometimes if I use breakpoints I can get it to show me the UI for longer periods of time an then while being in a debug pause the screen will suddenly disappear and the debugger will stop responding. Sometimes it'll still work while in breakpoints but once I resume the session the screen will go black.

So now come my questions and me asking for advice. How come the same source code can be debugged without a problem on the evka board but crashes on ours? Why was I able to debug the first version of the example code on the custom board without a problem but then a later one would fail but will work on the evka board? It really puzzles me. Of course I accept that there might be some hardware issue with our board but why does it show only in specific cases? I'll appreciate all kinds of ideas and advice. I really want to get to the bottom of it. If you need more info I'll gladly provide it.

[jeremyzhou]

Hi，
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, whether your board can run the more complex UI interface demo well after programming the image to the QSPI.
Next, whether your board is as same as the MIMXRT1050 EVK board.
Plus, what's the working clock frequency of SDRAM?
Have a great day,
TIC

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

[ap213]

Hi,

Thank you for your response. I'll address your questions and then provide some new insights on the problem.

  * "Firstly, whether your board can run the more complex UI interface demo well after programming the image to the QSPI": sadly the answer is no. The code is successfully uploaded to flash, the debugger stops at the first automatic break point at the beginning of main() and when I resume the debug session I see a short flash of the UI on the display and then the screen turns black. From this point on I can neither pause the debugger nor set any breakpoints. It looks like the processor just gets stuck. I have a separate thread from the UI wich flashes an LED on the board in order to show if it's running and the LED doesn't flash after the screen goes dark.

  *  "Next, whether your board is as same as the MIMXRT1050 EVK board": also no. Our custom board has the same processor but uses a slightly different flash and sdram. The ones that I have mentioned in the original post. The connections to these peripheries however are equivalent to the ones on the MIMXRT1050 EVK board.

  * "Plus, what's the working clock frequency of SDRAM?": The working clock frequency is the same as the one of the SDRAM on the MIMXRT1050 EVK board. I'am using the same configuration in order to avoid possible missmatches.

My most recent test show that if I unplug the display from the 40 pin connector, the debug session starts without a problem the LED is blinking as to show that the code is running and it's possible to set breakpoints, pause and resume the program. Once I connect the display to the 40 pin connector I directly experience the same problem as before. I'm quite puzzled as to what might be happening. Do you have any idea how the connection to the display might be influensing the code execution? It's weird because the communication with the display happens over the RGB interface and thus it's a one way communication comming only from the MCU (as far as I'm informed).

Best regards.

[jeremyzhou]

Hi,
Thanks for your reply.
After digging deeper, I guess it may be related to the DCD, evkbimxrt1050_littlevgl_guider demo uses the SDRAM as the primary RAM, which is benefit from the DCD feature which initializes the SDRAM prior to jumping to application.
The DCD will configure the SEMC to work at 163.8 MHz and it exceeds the maximum frequency of IS42S16160G-7BLI, so I think you need to adjust the DCD to fit the IS42S16160G-7BLI.

Have a great day,
TIC

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

[ap213]

This might be the problem, but it wouldn't explain why it worked for a smaller UI. I'd expect it to not work at all. However we tried the same code and configuration on a new custom board and it worked. So I'd say we have some hardware issue on the older one and that was the reason for the failure. Thank you for your help. I believe the topic can be closed now.