Issues flashing an XE216 micro Topic is solved

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
User avatar
mattb
Member
Posts: 13
Joined: Wed Aug 28, 2019 11:45 pm

Issues flashing an XE216 micro

Post by mattb »

Hello,

I'm bringing up a new board for with a XE216 on it. This is the first time using these new XMOS chips, we've previously done alot of work with the older XS1-U6A series.

I am having a hard time flashing the chip. I can write a program, and if I run or debug it from XTC IDE, it works fine. The program I wrote was very simple, it just toggled a GPIO every 500 msec, and I could see it do that on a scope. However, if I go to flash it, it says that the flashing has succeeded, but when I power cycle and start it, the GPIO doesn't toggle and it appears to be hung.

We are using an ISSI IS25LQ016B chip, which is pretty much identical to the XMOS' xCORE-200 multichannel dev kit's SPANSION S25FL116K (according to XTC14.3.3\target\include\QuadSpecMacros.h). I am using the following simple command line in the XTC prompt to program it:
xflash mysample.xe

I get the following warnings (that I don't when I flash the dev kit with its compiled reference firmware):
xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz
xflash: Warning: F03149 QE_REGISTER and/or QE_BIT locations not found in XN file for this flash device. Using default quad_spi_qe_location_status_reg_0 and quad_spi_qe_bit_6.

But it still goes through and says it was successful.

I do an erase/program/read with the command line, and I do see data read from the ISSI flash. And it kinda looks okay....if I do a dry run of the xflash with the -o parameter, the binary produced by that appears at 0x3000 of the read data from the real flashing.

-----

Any thoughts? What are these warnings in xflash about QSPI clocks and pins, and where would I add that info? My XN file looks really close to the XN file from the dev kit (except for the ExternalDevices/Device@Type node).

Also, why would xflash load the correct binary, but at offset 0x3000...might that be the issue why it's not starting up when I power cycle?

Thanks for any info!


View Solution
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Hi mattb,

The xCORE-200 explorer kit also uses the XE216 and IS25LQ016B. The XN file provided by xmos includes the following:

Code: Select all

  <ExternalDevices>
    <Device NodeId="0" Tile="0" Class="SQIFlash" Name="bootFlash" Type="S25FL116K">
      <Attribute Name="PORT_SQI_CS" Value="PORT_SQI_CS"/>
      <Attribute Name="PORT_SQI_SCLK"   Value="PORT_SQI_SCLK"/>
      <Attribute Name="PORT_SQI_SIO"  Value="PORT_SQI_SIO"/>
      <Attribute Name="QE_REGISTER" Value="quad_spi_qe_location_status_reg_0"/>
      <Attribute Name="QE_BIT" Value="quad_spi_qe_bit_6"/>
    </Device>
  </ExternalDevices>
You should have something like this in your XN file.

The clock warning isn't a problem as the device is faster. Correcting the XN file should sort out the other warnings. I'm not sure about your xflash problem - you could try setting xtc for verbose output and checking the command line it produces.

You can search in the installation folders for the XN file or just create a dummy project for the explorer kit and XTC will add a copy.

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

Post by mon2 »

If still not working, can you post the relevant part of the schematic for a quick review of the flash interface; power supply; power supply sequencing / reset; boot pins of the CPU?

Do check against the checklist posted inside the datasheet for your CPU that should offer more details on this topic.
User avatar
mattb
Member
Posts: 13
Joined: Wed Aug 28, 2019 11:45 pm

Post by mattb »

Thanks for the replies. Adding the QE Register and QE Bit to the XN file got rid of the errors, but the problem still exists.

I'm pretty sure my flash is working, I can see it programming data (on the scope), plus when I read back the contents are there. Here is what I've done:
  • Build a very simple app that only toggles the GPIO
  • "Run" the app through the XTC 14.3.3 IDE and the XTAG (so running it in RAM) --> it toggles the GPIO perfectly on the scope
  • Erase the chip
  • Read back the chip --> it's all 0xFF's, that's good
  • Flash the program that was built, which says it was successful
  • Power cycle --> no GPIO toggling
  • Read back the chip --> it's not all 0xFF's, it has actual data in the contents

I've attached my simple program here. In it is a make file that includes the commands I use to test it out:
  1. xmake -- build the program
  2. xmake eraseandread -- erases, and then reads the memory and dumps it to a file
    xflash --erase-all --target-file=$(XN_FILE)
    xflash --target-file $(XN_FILE) --read-all -o bin/$(APP_NAME).readaftererase.bin
  3. xmake flashandread -- flashes, and then reads the memory and dumps it to a file
    xflash --boot-partition-size 0x0001F0000 $(XE_FILE) --upgrade 1 $(XE_FILE)
    xflash --target-file $(XN_FILE) --read-all -o bin/$(APP_NAME).readafterflash.bin
  4. xmake genbin -- generates a binary that can be used in a firmware update process (useful for comparison)
    xflash --target-file $(XN_FILE) --upgrade 1 $(XE_FILE) --factory-version 14.3 -o bin/$(APP_NAME).genbin.bin
Note, that the file generated by the step #4 does exist in the file read in step #3...it just occurs at offset 0x2000. I think this is my problem, as when I did it in my original hack of the Multichannel reference firmware to test this (original post), this file occurred at offset 0x3000 (so it gets moved around maybe depending on size?)

Again, probably just something I missing with the way xflash places things, and maybe how that's now different in the X200 series.

-----

Thanks for any info! See my very small sample project, code, makefile, and binaries, all atttached in the ZIP. I've also attached a portion of our schematic relating to the FLASH, but I don't think that's the problem, as I've verified I can read and write to it from the XMOS
Attachments
schematic.jpg
(147.08 KiB) Not downloaded yet
schematic.jpg
(147.08 KiB) Not downloaded yet
app_flashtest.zip
(35.44 KiB) Downloaded 255 times
app_flashtest.zip
(35.44 KiB) Downloaded 255 times
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

X0D04, X0D05 and X0D06 all need to be pulled down to boot from QSPI flash, or left open as the XE216 has weak pull-downs.

The select signal X0D01 should be pulled up as you have it.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

As per @CousinItt, if you have R203 installed with a 10k, please remove this pull-up resistor from your assembled PCB and test again.
cousin_itt.jpg
cousin_itt.jpg (3.45 KiB) Viewed 58791 times
cousin_itt.jpg
cousin_itt.jpg (3.45 KiB) Viewed 58791 times
ps: Loved the (original) show growing up.

With R203 installed, you are forcing the boot mode pattern of "100" onto XS1_Port_4B whereas for QSPI boot the boot mode pattern should be "000".
xmos_qspi_boot_mode.png
(90.89 KiB) Not downloaded yet
xmos_qspi_boot_mode.png
(90.89 KiB) Not downloaded yet
So please remove R203, test again and post your results. The default internal pull-down resistors should be ok to assert the boot mode pattern to be "000" onto X0D04..X0D06.

Also, please review and test AN00185 and post your results.
User avatar
mattb
Member
Posts: 13
Joined: Wed Aug 28, 2019 11:45 pm

Post by mattb »

Hello all, thank you so much for your help. A bit of progress, but also a bit more a mystery.

First off though, removing that R203 pullup (on the X0D06) did help alot. Now (with the internal pulldowns), I think we are finally set to the boot mode 000 and it is much happier. My simple program above now flashes and runs on a cold boot.....some of the time -> that's the next mystery :)

So it is now running, but only about 20% of the time on a cold boot. The other 80% of the time nothing happens (no GPIO toggling via that simple example program I provided). For testing, I simplified my flash command to just be:
xflash --verbose --boot-partition-size 0x0001F0000 bin/app_flashtest.xe

I ran the command and am attaching the verbose output of the xflash command to this post. I also did a read of the flash and I can easily see that the the flash is empty (I did an erase before) after 0x2000, but there is data before that (i'm assuming the flash loader and then the binary)...also attached is that read data.

During the 20% of the time when it succeeds, I do a xrun --dump-state, and have included that output....it looks normal and correct. I also included a dump-state for the 80% case where it is hanging, and the dump-state looks very weird (like the micro is wedged).

Any thoughts? I'm flashing good now, but it is not consistently starting up. Thanks for your help!

P.S. - Attached is the 4 debug things I mentioned in a zip.
Attachments
DebugOutput.zip
(11.66 KiB) Downloaded 231 times
DebugOutput.zip
(11.66 KiB) Downloaded 231 times
User avatar
mattb
Member
Posts: 13
Joined: Wed Aug 28, 2019 11:45 pm

Post by mattb »

Another thing I've just noticed, is that if I use xgdb to reset the XMOS with this command:
xgdb --batch-silent --ex "connect" --ex "reset mode-pins nointerrupt" --ex "q"
then if I was in the 80% hung case, it will start working.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

That is really positive news to hear :)

The issue with flaky reset may be linked to your power sequencing and reset supervisor. Can you share the power supply and reset supervisor part of your schematic for a quick review?
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Also, what are the details of your clock source?

PLL values?

During the non-working state, is your clock stable?

Review section 7 of the XE216 datasheet for more details.

Power supply current ample for each of the rails?

Soldering is solid by a qualified contract manufacturer? In many past reviews of similar designs, often the metal pad on the CPU was not soldered properly which led to assorted issues.
Post Reply