cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
aaron_b1
Explorer
Explorer
973 Views
Registered: ‎12-20-2017

QSPI Woes. Is mtd_debug erase/read/write a supported thing to use to test QSPI?

Jump to solution

I'm working with a custom board with petalinux 2018.2 that I think has messed up QSPI.  The platform was developed on 2017.2. I understand mixing 2017.2 platforms with 2018.2 petalinux is not fully supported.  I've had good luck, and no reason to think the version mismatch is giving me any trouble (yet).

I believe the board has hardware issues, but I want to make sure my software techniques are not adding to my problems.

1) Using the SDK, I imported the hdf from the vivado and created a bare metal application, using the source from xqspipsu_generic_flash_interrupt_example.c.  I was able to modify this test to write the whole of my QSPI addressible space (128MB).  Everything worked fine. 

2) However, when I bring the HDF into petalinux and get to the command line, things start to get flakey. I can write a file to the mtd3 partition, and read it back multiple times, getting different results each time, and I'd like confirmation that my techniques are sound, expecially whether using mtd_debug is a good idea.

I'm familiar with https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842262/Zynq+QSPI+Driver#ZynqQSPIDriver-QSPIflashtestingwithflashcp, but flashcp only tells me that something doesn't match at a certain offset, and I wanted to be able to tell the hardware engineers a little more, so I moved toward mtd_debug.

 

# first, verify that flashcp fails:
$ flashcp -v random.bin /dev/mtd3
Erasing blocks: 128/128 (100%)
Writing data: 1024k/1024k (100%)
Verifying data: 10k/1024k (0%)File does not seem to match flash data. First mismatch at 0x00000000-0x00002800

# Let's get more info on what the failures look like.

$ cat /proc/mtd dev: size erasesize name mtd0: 01e00000 00002000 "boot" mtd1: 00040000 00002000 "bootenv" mtd2: 03dc0000 00002000 "kernel" mtd3: 02400000 00002000 "application"

# Create the test file of 1MB $ dd if=/dev/urandom count=1024 bs=1024 of=random.bin 1024+0 records in 1024+0 records out


# Erase the whole device $ mtd_debug erase /dev/mtd3 0 0x02400000 Erased 37748736 bytes from address 0x00000000 in flash
# Write the test file to it, then read it back
$ mtd_debug write /dev/mtd3 0 1048576 random.bin Copied 1048576 bytes from random.bin to address 0x00000000 in flash $ mtd_debug read /dev/mtd3 0 1048576 read.bin Copied 1048576 bytes from address 0x00000000 in flash to read.bin

# It's different $ diff random.bin read.bin Files random.bin and read.bin differ
# Read it again. Should be the same as the first read, but it's not
$ mtd_debug read /dev/mtd3 0 1048576 read2.bin Copied 1048576 bytes from address 0x00000000 in flash to read2.bin $ diff read.bin read2.bin Files read.bin and read2.bin differ

 

You can see from the difference (between the last two reads) that the differences are usually one bit, but sometimes two bits.  It is not always the high nibble or low nibble (I believe my two QSPI chips are split - one takes the high nibble and the other takes the low) I believe I have a data corruption problem on the QSPI data bus;

Capture.PNG

 

Any tips about process are certainly welcome.

 

0 Kudos
1 Solution

Accepted Solutions
aaron_b1
Explorer
Explorer
901 Views
Registered: ‎12-20-2017

The corruption problem was solved by slowing down the SPI clock from 300MHz to 100MHz. 

Once the corruption was cleared up, mtd_debug produced consistent results, so it appears it is a valid thing to use to test QSPI problems.

 

View solution in original post

0 Kudos
1 Reply
aaron_b1
Explorer
Explorer
902 Views
Registered: ‎12-20-2017

The corruption problem was solved by slowing down the SPI clock from 300MHz to 100MHz. 

Once the corruption was cleared up, mtd_debug produced consistent results, so it appears it is a valid thing to use to test QSPI problems.

 

View solution in original post

0 Kudos