flash with xtimecomposer and command prompt cause different flash content

New to XMOS and XCore? Get started here.
TonyXiao
Active Member
Posts: 44
Joined: Fri Mar 29, 2019 3:58 am

flash with xtimecomposer and command prompt cause different flash content

Post by TonyXiao »

Hi guys

when i flash the same xe file with xtimecomposer and command prompt, they are in same version of 14.3.3.
and read the flash content out, found they are different. though the working result seem all the same.

my board xlinks one XUF232 and one XU208, both of the 2 xmos works well as 1 XMOS. i compared the flash contents, and the upper part is flash by xtimecomposer the other is by command prompt.

some of the diffents, there seems rules to replace the data such as: 3A-->ED, 2D-->0D, 55-->65,D6-->E6,...
and one special rule is add 00 before 38 8D at the address 0x5818,(38 8D only one place of all the content)
compare-flash-content.png
compare-flash-content.png (20.25 KiB) Viewed 3840 times
compare-flash-content.png
compare-flash-content.png (20.25 KiB) Viewed 3840 times
compare-flash-content3.png
compare-flash-content3.png (19.27 KiB) Viewed 3840 times
compare-flash-content3.png
compare-flash-content3.png (19.27 KiB) Viewed 3840 times
and beside the replace rules at the end there are 4 bytes moved back overall.
compare-flash-content2.png
(20.62 KiB) Not downloaded yet
compare-flash-content2.png
(20.62 KiB) Not downloaded yet
when try doing the same thing without xlink xu208, only using XUF232, and the 2 flash methods have the same flash content.
reading the datasheet, such XUF232 can be looked as 2 XU216 xlink together, but why when i xlinks caused the differnt result?


BR,
tony


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Suspecting that you are getting data corruption during the read or write process when working with the flash component. A few years ago, we found that the QSPI flash pin drive strengths varied by a great deal against the tested vendors. Back then SPANSION was very strong and we could have long (but shielded) logic analyzer cables (from Zeroplus, Taiwan) and could run at relatively high data rates without data corruption. Yet, Winbond (back then) could not. We chatted with Winbond and their Taiwan office shipped us replacement parts via courier with devices that featured a pin strength register - believe the results were then similar for the tested cables after the use of this aux register. Just a FYI.

In the command line tools, using xflash, pass a slower clock value for the SPI clock and test again to erase -> write -> read back the contents for a compare.

Are the results improved and match or still mismatched if you pass a slower SPI clock value?

The default SPI clock is 15.62Mhz for the SPI clock. You can verify the SPI clock value with a scope.

Try:

Code: Select all

--quad-spi-clock 5Mhz

Use the following to receive more info on the parameters that can be passed with xflash tool:

Code: Select all

 XFLASH --help

Code: Select all

  --quad-spi-clock arg       Set the Quad SPI clock for the second stage
                             loader;
                             arg = <5MHz|6.25MHz|8.33MHz|12.5MHz|13.88MHz|15.62
                             MHz|17.85MHz|20.83MHz|25MHz|31.25MHz|41.67MHz|50MH
                             z>
Please post your test results.
TonyXiao
Active Member
Posts: 44
Joined: Fri Mar 29, 2019 3:58 am

Post by TonyXiao »

Hi mon2

follow your advice, i slow down the clock to 5Mhz when xflash xe file, and read out the flash content, found there are only 4 different places now.
compare-5MHz.png
(27.81 KiB) Not downloaded yet
compare-5MHz.png
(27.81 KiB) Not downloaded yet
such differents seems are all in flash loder part, the runing code part are same. is it correct?
the XUF232 are integrated one IS25LQ016B inside.it should be well tested before integrated in XMOS chip.
xtimecomposer flash with default clock 15.62Mhz, command prompt flash with clock 5Mhz, have the minimal different parts (only 4 part), but which xflash method should I trusted?

trying use same command prompt generate the bin files with different clock speed.
xflash xxx.xe -o xxx.bin and xflash xxx.xe -o xxx.bin --quad-spi-clock 5MHz, and compare them, and the same 4 part different part are found as show at the start part. so maybe the different clock speed cause the different flash content, it gives me much joy.
if it is true the bin files generate with xflash xxx.xe -o xxx.bin and xflash xxx.xe -o xxx.bin --quad-spi-clock 15.62MHz should be same, because the are all using 15.62MHz, but the result is not the same, they are almost totally different.
Getting more confused.

BR,
Tony
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi.

1) use xflash to write the binary file to an output file, not the flash chip. See xflash tool user guide on how to do this.

2) then repeat the same process using a new file name

3) now use any free hex file editor and compare the 2 files.

Do the files match?

Check the same location offset as the xflash process.

Post your results.
TonyXiao
Active Member
Posts: 44
Joined: Fri Mar 29, 2019 3:58 am

Post by TonyXiao »

Hi mon2

sorry i am quite not understand. can you give me such xflash tool user guide website link?
TonyXiao
Active Member
Posts: 44
Joined: Fri Mar 29, 2019 3:58 am

Post by TonyXiao »

Hi mon

if you mean do this: xflash xxx.xe -o xxx.bin, and using different name.
i have tried several times, they are all the same.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Ok. Now compare one of output files against the dump from a programmed flash.

Are there any mismatched bytes?

Is your project using a DFU bootloader?

Does the flashed IP work correctly?

Test with a simple led blinky code (no DFU) and check if any bytes mismatch.

Do the same using any XMOS official kit. Any mismatched bytes?

How many layers is your PCB? How far is the flash away from the CPU?

Can you post a schematic of the design for a quick review?
TonyXiao
Active Member
Posts: 44
Joined: Fri Mar 29, 2019 3:58 am

Post by TonyXiao »

Hi mon2

xtimecomposer xflash with default 15.62MHz flash content is same as output bin file by xflash generate with default 15.62MHz;
xtimecomposer xflash with default 15.62MHz flash content is different with output bin file generate with specify 15.62MHz clock;
command prompt xflash with specify 5MHz clock flash content is same as output bin file generate with specify 5MHz clock;

yes, dfu is enabled.
both of xtimecomposer xflash and command prompt xflash, all the function are working well.without compare the flash content, they looks same;
i have do the same test on the xCore-200 explorer board, found both of the two xflash methods the flash content are all same; this board use XE216, working with one external flash; as to my board use XUF232(flash inside), and xlinks with one XU208;

our board have 8 layers, and the flash is inside the XUF232, two chip is xtag as johned posted here: https://www.xcore.com/viewtopic.php?f=8 ... ink#p35316
TonyXiao
Active Member
Posts: 44
Joined: Fri Mar 29, 2019 3:58 am

Post by TonyXiao »

Hi all

i am getting more confuesd,all my experience is breaking.
using xcore-200 explorer board, with demo project AN00155_explorer_gpio, without changing anything on the code side
just build it yesterday and today, compare the build xe file and they are different. after xflash the xe file, read them out, the flash content yesterday and today are different too. i have double checked the function,the right led light on as i pushed the button.
build-time-cause-different.png
(22.19 KiB) Not downloaded yet
build-time-cause-different.png
(22.19 KiB) Not downloaded yet
i don't know where to go now.
can some guys help doing the same test on your official board on hand? and tell me the result.
Thanks.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi.

1) Use xflash in command line mode and perform a full chip erase

2) then read back the contents of your flash using xflash and output the contents to a local file

3) Read in the generated flash dump file into your hex editor.

4) Check the range of the flash memory size in your editor to confirm that all values inside the buffer are now blank = 0xFF. Are the locations all blank?

=====

Then,

5) program with the GPIO appnote from XMOS -> confirm the appnote works correctly. If it does and it should, dump the contents to a local file and name it dump1.bin or similar.

6) Use xflash in command line mode and perform a full chip erase

7) Read in the generated flash dump file into your hex editor.

8) Check the range of the flash memory size in your editor to confirm that all values inside the buffer are now blank = 0xFF. Are the locations all blank?

9) program with the GPIO appnote from XMOS -> confirm the appnote works correctly. If it does and it should, dump the contents to a local file and name it dump2.bin or similar.

Compare dump1.bin against dump2.bin with command prompt mode of Windows:

Code: Select all

fc /b dump1.bin dump2.bin > diff.txt
Do the files match or are different?

Q: Is the XMOS kit the factory original or has been modified? Perhaps the flash device has been changed?

For your testing, use the same PC, same cables, same XMOS toolchain.
Post Reply