Accessing LS1021A-TWR QSPI

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Accessing LS1021A-TWR QSPI

Jump to solution
3,184 Views
jasonhendrix
Contributor V

I'm trying to write a bare-metal program that accesses the QSPI on my LS1021A-TWR X3 board.  Neither my program, nor the CodeWarrior flash programmer task can access it.  The Flash Programmer actually reports success of the diagnoses, but the ID it reports tells another story:

Flash Information  

=================  

Flash Manufacturer ID     :0x000000FF

Flash Device ID (byte1)   :0x000000FF

Flash Device ID (byte2)   :0x000000FF

Flash Device ID (byte3)   :0x0000FFFF

Secure Device Verification:0x00000000

  

Diagnose Succeeded  

I'm debugging with Code Warrior TAP over USB.

Do I need a special configuration of Switches or config files in order to access the flash?  My project is using the init file provided by CodeWarrior LS1021A-TWR_Init.tcl.  Thanks.

Labels (1)
1 Solution
2,247 Views
addiyi
NXP Employee
NXP Employee

Make sure you use the correct setting for Target RAM:

pastedImage_1.png

And also correct Address Offset when programming into qspi:

pastedImage_2.png

fl::target -lc "ls1021atwr-core0_RAM_LS1021ATWR_Download"

fl::target -b 0x10000000 0x20000

fl::target -v off -l off

cmdwin::fl::device -d "N25Q128A" -o "16Mx8x1" -a 0x40000000 0x40ffffff

cmdwin::fl::image -f "X:\\QorIQ-SDK-V1.9-20151210-yocto\\build_ls1021atwr\\tmp\\deploy\\images\\ls1021atwr\\u-boot-qspi.bin" -t "Auto Detect" -re off -oe on -o 0x40000000

cmdwin::fl::write

Beginning Operation ...   

-------------------------

Programming file X:\QorIQ-SDK-V1.9-20151210-yocto\build_ls1021atwr\tmp\deploy\images\ls1021atwr\u-boot-qspi.bin  

Auto-detection is successful.  

  File is of type Binary/Raw Format.  

Performing target initialization ...   

Downloading Flash Device Driver ...  

Reading flash ID ...

Auto-detection is successful.  

  File is of type Binary/Raw Format.  

Downloading 0x00010000 bytes to be programmed at 0x40000000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40010000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40020000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40030000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40040000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40050000  

Downloading 0x0000AA60 bytes to be programmed at 0x40060000  

Executing program ....  

Program Command Succeeded   

cmdwin::fl::dump -range 0x40000000 0x40080000 -t "Binary/Raw Format" -o "C:\\Users\\b11883\\Desktop\\qspi_dump.bin"

-------------------------

Downloading Flash Diagnostics Driver ...  

Reading flash ID ...

Dumping flash region: 0x40000000 - 0x40080000 to C:\Users\b11883\Desktop\qspi_dump.bin  

Running Dump Flash ...  

Running Dump Flash ...  

Running Dump Flash ...  

Running Dump Flash ...  

Running Dump Flash ...  

Dump Flash Succeeded 

Adrian

View solution in original post

17 Replies
2,247 Views
jasonhendrix
Contributor V

To summarize  - the things that helped me:

* Configure the run configuration with the QSPI cfg file.  For me, this was at: C:\Freescale\CW4NET_v2016.01\CW_ARMv7\ARMv7\ARM_Support\Configuration_Files\jtag_chains\LS102xATWR_RCW_1000-300-1600_QSPI.txt

*  I changed a value in that file as described in this thread (search for "4108").  I haven't checked to see if it works without that change.

* SW2: 0010_0111

* Setting the proper offsets in the flash programmer task

  * 0x10000000 for the Target RAM

  * 0x40000000 for the "Apply Address Offset" option

  * 0x40000000 for the Flash Device Base Address (column in table in "Add Program/Verify Action" dialog)

* booting from SDCard with the .bin attached in this thread

2,248 Views
addiyi
NXP Employee
NXP Employee

Make sure you use the correct setting for Target RAM:

pastedImage_1.png

And also correct Address Offset when programming into qspi:

pastedImage_2.png

fl::target -lc "ls1021atwr-core0_RAM_LS1021ATWR_Download"

fl::target -b 0x10000000 0x20000

fl::target -v off -l off

cmdwin::fl::device -d "N25Q128A" -o "16Mx8x1" -a 0x40000000 0x40ffffff

cmdwin::fl::image -f "X:\\QorIQ-SDK-V1.9-20151210-yocto\\build_ls1021atwr\\tmp\\deploy\\images\\ls1021atwr\\u-boot-qspi.bin" -t "Auto Detect" -re off -oe on -o 0x40000000

cmdwin::fl::write

Beginning Operation ...   

-------------------------

Programming file X:\QorIQ-SDK-V1.9-20151210-yocto\build_ls1021atwr\tmp\deploy\images\ls1021atwr\u-boot-qspi.bin  

Auto-detection is successful.  

  File is of type Binary/Raw Format.  

Performing target initialization ...   

Downloading Flash Device Driver ...  

Reading flash ID ...

Auto-detection is successful.  

  File is of type Binary/Raw Format.  

Downloading 0x00010000 bytes to be programmed at 0x40000000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40010000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40020000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40030000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40040000  

Executing program ....  

Program Command Succeeded   

Downloading 0x00010000 bytes to be programmed at 0x40050000  

Downloading 0x0000AA60 bytes to be programmed at 0x40060000  

Executing program ....  

Program Command Succeeded   

cmdwin::fl::dump -range 0x40000000 0x40080000 -t "Binary/Raw Format" -o "C:\\Users\\b11883\\Desktop\\qspi_dump.bin"

-------------------------

Downloading Flash Diagnostics Driver ...  

Reading flash ID ...

Dumping flash region: 0x40000000 - 0x40080000 to C:\Users\b11883\Desktop\qspi_dump.bin  

Running Dump Flash ...  

Running Dump Flash ...  

Running Dump Flash ...  

Running Dump Flash ...  

Running Dump Flash ...  

Dump Flash Succeeded 

Adrian

2,247 Views
jasonhendrix
Contributor V

Thanks Adrian.  That's what was missing. Both the flash programmer and my test app are working.

0 Kudos
2,247 Views
addiyi
NXP Employee
NXP Employee

Please use attached uboot for sd-card, which enable qspi (this is also available in SDK 1.9). To program this uboot into the sd card you can use CW, import LS102xATWR_SD_FLASH Target Tasks, and set the offset address to 0x1000. Or you can mount your sd card into a host linux and use the command:

sudo dd if=u-boot-sdcard-qspi.bin of=/dev/<sd card mount> seek=8

Adrian

0 Kudos
2,247 Views
jasonhendrix
Contributor V

I used the CW approach to successfully add the .bin to the SDCard.

0 Kudos
2,247 Views
jasonhendrix
Contributor V

sf erase, read, and write work in u-boot.  I'm further convinced that the issue is in my CW configuration.

0 Kudos
2,247 Views
jasonhendrix
Contributor V

Interaction with flash via CW and TAP is still the same.  "Operation unsupported".  There is some good news - booting from the SDCard with the image you attached to your last post worked.  I was able to sf probe, then read flash.  And, the data I read from U-boot is the same as the data I read from CW at addr 0x40000000.  So some parts of it are working.  I'm just not able to program flash with CW and TAP.  Attached is a screenshot immediately after attempting a flash programming task:

pastedImage_0.png

The diagnose operation and my application still read all 0xFF as well.

I will attempt a program and erase from u-boot just to verify that works.

I suspect there's something wrong with my debug configuration.  Is it possible that there's a step-by-step procedure documented for programming QSPI flash?  Maybe I can take my projects and debug configurations out of the equation...

0 Kudos
2,248 Views
addiyi
NXP Employee
NXP Employee

Here is my Diagnose running on board booting from sd, using u-boot-sdcard-qspi.bin and SW2: 0010_0111

fl::target -lc "ls1021atwr-core0_RAM_LS1021ATWR_Download"

fl::target -b 0x10000000 0x20000

fl::target -v off -l off

cmdwin::fl::device -d "N25Q128A" -o "16Mx8x1" -a 0x40000000 0x40ffffff

cmdwin::fl::diagnose full

Beginning Operation ...   

-------------------------

Performing target initialization ...   

Downloading Flash Diagnostics Driver ...  

Reading flash ID ...

Running Diagnostics ...  

Running Diagnostics ......................................

Sector Map (read from target)  

=============================  

Sector 00000: 0x40000000 - 0x4000FFFF Size=0x00010000 unprotected programmed  

Sector 00001: 0x40010000 - 0x4001FFFF Size=0x00010000 unprotected programmed  

Sector 00002: 0x40020000 - 0x4002FFFF Size=0x00010000 unprotected programmed  

Sector 00003: 0x40030000 - 0x4003FFFF Size=0x00010000 unprotected programmed  

Sector 00004: 0x40040000 - 0x4004FFFF Size=0x00010000 unprotected programmed  

Sector 00005: 0x40050000 - 0x4005FFFF Size=0x00010000 unprotected programmed  

Sector 00006: 0x40060000 - 0x4006FFFF Size=0x00010000 unprotected programmed  

Sector 00007: 0x40070000 - 0x4007FFFF Size=0x00010000 unprotected      blank

.....

Flash Information  

=================  

Flash Manufacturer ID     :0x00000020

Flash Device ID (byte1)   :0x000000BA

Flash Device ID (byte2)   :0x00000018

Flash Device ID (byte3)   :0x00004323

Secure Device Verification:0x00000000

  

Diagnose Succeeded

Adrian

0 Kudos
2,248 Views
jasonhendrix
Contributor V

Still no luck when booting from the SD card.  I tried to use the SDCard that came with the dev board.  I don't know think this was the proper image because, even though it booted to U-Boot, there was no sf command in U-boot, just nor flash commandss.  Unless you have more suggestions, I'll delay debugging this issue until the custom HW arrives.  Thanks for the help.

0 Kudos
2,248 Views
jasonhendrix
Contributor V

Do I need to power-up in SD Boot mode in order to access QSPI with CodeWarrior and TAP?  I'll give it a try.

0 Kudos
2,248 Views
addiyi
NXP Employee
NXP Employee

Hi Janson,

To be able to access qspi, with no switch settings, you have to use RCW12 = 0x20024800. So, you can use jtag chain file as Target type in CW and add the new value for RCW12 in rcw index 4108.

Also, please try a Program/Verify Action, follow by a Dump Action. It is possible that Flash Programmer to return wrong Manufacturer ID.

Adrian

0 Kudos
2,248 Views
jasonhendrix
Contributor V

This first response got lost, so I'll post again...

I added the file C:\Freescale\CW4NET_v2016.01\CW_ARMv7\ARMv7\ARM_Support\Configuration_Files\jtag_chains\LS102xATWR_RCW_1000-300-1600_QSPI.txt

to my debug config target type.  In that file, I changed (4108 0x20024000) to (4108 0x20024800).

Is this the filetype to use, or were you referring to the jtag.cfg type file?

My app and Flash Programmer still not working, but as posted previously, I now read 0xFF from 0x40000000 instead of 0x00.

My config:

pastedImage_0.png

0 Kudos
2,248 Views
addiyi
NXP Employee
NXP Employee

Could you try to set SW2.5=0 and check again. It seems is mandatory QSPI bus to be enabled.

Adrian

0 Kudos
2,248 Views
jasonhendrix
Contributor V

I wonder if maybe I don't have the clocks configured properly.  The QSPI module is apparently sampling the inputs, because it's placing the correct number of 0xFF bytes in the RX buffer.  Is that a good indication that the QSPI clock is running?

I'm not doing any explicit configuration of the clocks - just using what's on the dev board and is configured in the QSPI debug config file...

0 Kudos
2,248 Views
jasonhendrix
Contributor V

Programmer task still returns 0xFF after setting SW2.5 = 0.

Sector 00255: 0x00FF0000 - 0x00FFFFFF Size=0x00010000 unprotected programmed  

Flash Information  

=================  

Flash Manufacturer ID     :0x000000FF

Flash Device ID (byte1)   :0x000000FF

Flash Device ID (byte2)   :0x000000FF

Flash Device ID (byte3)   :0x0000FFFF

Secure Device Verification:0x00000000

It does seemed to have changed the readout - from 0x40000000 I now read 256 bytes of 0x55, 256 bytes of 0xAA, then all 0xFF. 

0 Kudos
2,248 Views
jasonhendrix
Contributor V

Something that is new (probably due to the new config file), is that a memory monitor view onto 0x40000000 now shows all 0xFFFFFFFF.  Previously, it showed all 0x00000000.

0 Kudos
2,248 Views
jasonhendrix
Contributor V

I removed the "erase before programming option" in the flash programmer task, but same problem:

fl::target -lc "QSPIFlashTest-core0_RAM_LS1021ATWR_Download"

fl::target -b 0x80000000 0x4000000

fl::target -v off -l off

cmdwin::fl::device -d "N25Q128A" -o "16Mx8x1" -a 0x0 0xffffff

cmdwin::fl::image -f "C:\\Freescale\\CW4NET_v2016.01\\CW_ARMv7\\ARMv7\\ARM_Support\\FlashToolKit\\TestSrecFiles\\8k_at_0.S" -t "Auto Detect" -re off -oe off

cmdwin::fl::write

Beginning Operation ...   

-------------------------

Programming file C:\Freescale\CW4NET_v2016.01\CW_ARMv7\ARMv7\ARM_Support\FlashToolKit\TestSrecFiles\8k_at_0.S  

Auto-detection is successful.  

  File is of type Motorola S-Record Format.  

Performing target initialization ...   

Downloading Flash Device Driver ...  

Reading flash ID ...

Auto-detection is successful.  

  File is of type Motorola S-Record Format.  

Downloading 0x00002000 bytes to be programmed at 0x00000000  

Executing program ....  

Error:  Program failed.   Flash driver reports the following error(s):  Operation Unsupported

Error: Program failed. Flash driver reports the following error(s):  Operation Unsupported

0 Kudos