Hi,
I can use xrun to run a binary .xe file on one of my XCORE-200 Explorer boards, but when I try to use xflash, I get the attached error consistently, even after doing a complete erase with
xflash --target-file XCORE-200-EXPLORER.xn --erase-all
which completes successfully.
Any suggestions please?
xflash error on XCORE-200 Explorer Board
-
- Experienced Member
- Posts: 71
- Joined: Sun Apr 08, 2018 11:19 pm
xflash error on XCORE-200 Explorer Board
You do not have the required permissions to view the files attached to this post.
-
- Experienced Member
- Posts: 71
- Joined: Sun Apr 08, 2018 11:19 pm
Looking at some of the other posts, this seems to be a reoccurring error. This board was previously flashed successfully using xTIMEcomposer 14.4.1, and as I don't think there should be an issue with the XMOS-supplied XCORE-200-EXPLORER.xn, I am wondering whether an issue has been introduced with the XTC 15.3.0 tool chain?
This is what I get back from reading the flash registers:
I've also attached the .xn file for reference
Any suggestions please?
This is what I get back from reading the flash registers:
I've also attached the .xn file for reference
Any suggestions please?
You do not have the required permissions to view the files attached to this post.
-
- XCore Addict
- Posts: 224
- Joined: Tue Jan 17, 2017 9:25 pm
Hi Al.
Perhaps our issues are related. I'm looking a the QE bit and wondering if it has something to do with this. I wonder if you know how to read back the flash status register and set this bit?
Perhaps our issues are related. I'm looking a the QE bit and wondering if it has something to do with this. I wonder if you know how to read back the flash status register and set this bit?
-
- XCore Addict
- Posts: 224
- Joined: Tue Jan 17, 2017 9:25 pm
I think its going to be: xflash --target-file target.xn --spi-cmd 0x35 1. Or in my case its xflash --target-file target.xn --spi-cmd 0x05 1
-
- Experienced Member
- Posts: 71
- Joined: Sun Apr 08, 2018 11:19 pm
Hi RitchRock
Yes, I think we've uncovered the same issue, and I would welcome some input on how to resolve from XMOS please.
Yes, I think we've uncovered the same issue, and I would welcome some input on how to resolve from XMOS please.
-
Verified
- Experienced Member
- Posts: 86
- Joined: Sun Dec 13, 2009 1:12 am
Hi,
Sorry you've been having issues with this.
I've looked into this today and have been able to replicate the issue. I suspect this is only occurring on early xcore200 explorer boards with the Spansion S25FL116K flash. We're investigating the exact cause but it looks like the device has ended up having the status registers write protected which stops the tools setting the QE bit and this results in the verify failure.
You can confirm this is the case on your board by running:
xflash --target XCORE-200-EXPLORER --spi-command 0x05 1
This reads status register 1.
If this reads as 0xFC then it has write protection via the WP pin set.
We'll keep you updated on a fix.
Cheers,
Joe
Sorry you've been having issues with this.
I've looked into this today and have been able to replicate the issue. I suspect this is only occurring on early xcore200 explorer boards with the Spansion S25FL116K flash. We're investigating the exact cause but it looks like the device has ended up having the status registers write protected which stops the tools setting the QE bit and this results in the verify failure.
You can confirm this is the case on your board by running:
xflash --target XCORE-200-EXPLORER --spi-command 0x05 1
This reads status register 1.
If this reads as 0xFC then it has write protection via the WP pin set.
We'll keep you updated on a fix.
Cheers,
Joe
XMOS hardware grey beard.
-
- Experienced Member
- Posts: 71
- Joined: Sun Apr 08, 2018 11:19 pm
Hi Joe,
I confirm that status register 1 reads as 0xFC on this particular Explorer Kit board. Visual inspection also confirms that it is definitely an early version with a Spansion flash IC.
Thanks in advance for the fix.
Kind regards,
Al
I confirm that status register 1 reads as 0xFC on this particular Explorer Kit board. Visual inspection also confirms that it is definitely an early version with a Spansion flash IC.
Thanks in advance for the fix.
Kind regards,
Al
-
- Experienced Member
- Posts: 71
- Joined: Sun Apr 08, 2018 11:19 pm
Could you confirm the manufacturer and part number of the QSPI flash IC currently being fitted to XC-200 Explorer Boards please?
-
Verified
- Experienced Member
- Posts: 86
- Joined: Sun Dec 13, 2009 1:12 am
Hi,
We've identified the issue with the 15.3 tools now and are testing a fix.
For now, you can "recover" your board by running the attached binary which writes both lower status registers in the flash to 0x00. This will remove the write protection and set the registers back to their delivery defaults.
After running this you can use xflash as normal but must always use the option --spi-div=8.
If you use xflash without the --spi-div=8 option with 15.3 tools it may put the boards back into the same state.
Let me know how you get on, I've confirmed this works on an xcore-200 explorer board I have here which exhibited the same behaviour as yours.
Cheers,
Joe
We've identified the issue with the 15.3 tools now and are testing a fix.
For now, you can "recover" your board by running the attached binary which writes both lower status registers in the flash to 0x00. This will remove the write protection and set the registers back to their delivery defaults.
After running this you can use xflash as normal but must always use the option --spi-div=8.
If you use xflash without the --spi-div=8 option with 15.3 tools it may put the boards back into the same state.
Let me know how you get on, I've confirmed this works on an xcore-200 explorer board I have here which exhibited the same behaviour as yours.
Cheers,
Joe
You do not have the required permissions to view the files attached to this post.
XMOS hardware grey beard.
-
- Experienced Member
- Posts: 71
- Joined: Sun Apr 08, 2018 11:19 pm
Hi Joe,
Thanks very much, I confirm that this workaround fixes the issue for now.
I'll leave the thread unanswered so you can post when you have the actual fix available.
Kind regards,
Al
Thanks very much, I confirm that this workaround fixes the issue for now.
I'll leave the thread unanswered so you can post when you have the actual fix available.
Kind regards,
Al