(Reposting as last post was marked as spam?)
Hi!
We are developing an application on the MXRT1064 series of chips using a large, 10.1-inch touchscreen.
The display is from newhaven displays: https://www.newhavendisplay.com/nhd1011024600afasxvctp-p-9630.html
Before developing a new board to use this display, I created an adapter board between the standard EVK pinout for the smaller display and this larger display (this adapter board also has a better power supply to support the new backlight requirement). This seems to work fine for us without issues. All that needs to be changed in the example projects (like the LVGL demo widgets project) is the resolution and porch numbers and pixel clock frequency. However, I am unsure if the settings I am using are exactly correct, however, they mostly seem to work, little to no flickering and centered, high res picture with good framerate.
We have also tested this adapter board setup on other in-house boards that have the MIMXRT1064-DVL6A with the ISSI dram. Works well also.
Now, we have developed a larger, purpose-built, PCB for this application with the backlight circuitry built-in as well as the correct pinout for the display. This PCB is much larger than the existing ones. This PCB also uses the 1064DVJ6A version of the processor, which we have never worked with before. Our assumption is that the silicon is the same and as such, any project should work on both the DVL6A and DVJ6A? Is this correct? Is there any other considerations we should have made converting a design from DVL6A to DVJ6A? Effectively we left the schematic the same and relayed out the PCB for the larger chip.
On this new board projects like LED blinky run fine without any issues. Even when I add some DRAM stress tests it still runs fine. Display examples also look and run fine for some amount of time, until they hard fault at seemingly random intervals (sometimes a few seconds, sometimes a few minutes, sometimes longer), I get random hard faults on LVGL display projects that work without issues on the other boards (EVK and similar).
These range from mem-manage to bus fault to invalid instruction, etc... Pretty much everyone in the book.
I've been working for the last couple of weeks to isolate the issue, but I've been unable to do so. I've tried lowering the CPU clock speed, lowering the memory clock speed. Disabling the backlight of the display, etc... These are all with the newest SDK version of the LVGL demo widgets example. The only modification is modifying the display size constants and also the porch/pulse width constants. Other than these random hard faults, everything works correctly. And again, this exact same code works on the 1064 EVK board and our other in-house EVK like board which is both on the 1064DVL6A chip.
To us, these issues sound power-related or heat-related, however, I've largely ruled both of those out. We have a thermal camera and no issues are seen. All power supplies also look good. I've also tried the brown-out interrupt mentioned by the ARM spec and I never hit a breakpoint there.
One concern of ours is potentially routing the DRAM ISSI interface and the display interface. This board is fairly large, and the routing isn't perfect. However, I've written some DRAM read-write tests and no errors appear. I would also expect to see graphical issues if there is a routing issue with the ram/display rather than just a random hard fault after minutes. Is there anything I can run to try to validate the DRAM if that is causing some intermittent failure every once in a while?
At this point, I'm pretty lost on what the cause could be and I'm looking for any ideas that people have. My only theory right now is it's something related to switching from the DVL6A to the DVJ6A, but I have nothing to back that up right now. I've also considered that incorrectly setting the porch and width settings as well as the pixel clock speed could cause some sort of issue, but I've been unable to cause anything yet.
Hi Max,
As my colleague mentioned the difference between DVL6A to the DVJ6A is only the package so there should not be any operational difference that could be causing this issue.
Additionally to my colleague comments, I will recommend you to check your PCB routing, you mentioned that it could be some signal instability in your design, please check our hardware recommendations here: https://www.nxp.com/webapp/Download?colCode=MIMXRT105060HDUG
Best regards,
Felipe
See the following post for more info (the problem seems flash related?):