Problem programming pristine device with bin file Topic is solved

[daniel3550]

Is it possible to program factory-fresh devices from bin files?

We have tools that write bin files directly to QSPI flash in XUF216-512-FB236-C20. The bin files are generated by connecting an XTAG to the board and running

xflash app.xe -o app.bin

This works great. But now I have some pristine devices (never connected to an XTAG or programmed) and bin programming is not working.

• - After failed bin programming, I read flash using xflash --read-all. The 1st 4 bytes are 0x84 0x21 0xFC 0x35, and everything else is 0xFF. This makes me think the factory fresh part is write-protected somehow

• - I can connect an XTAG to a pristine device and program app.xe. After that, bin programming works fine. So it appears xflash is doing something to setup / unprotect a factory fresh part

I noticed in "Design and manufacture system with flash memory" it says

XFLASH generates an image in the xCORE flash format that contains a first stage
loader and factory image comprising the binary and data segments from your
compiled program. It then writes this image to flash memory using the xCORE
device.

Is the first stage loader included in the bin files created by xflash -o command? Or do I have to connect XTAG one time to get it into the device?

[mon2]

What are the details of your flash device? Is it on the supported list of flash devices? P/N and Vendor?

Also, apply the -v (Verbose) flag to your xflash commands to review the details of the process and post the results.

Please also review this document and post your status:

https://www.xmos.com/developer/download ... 283%29.pdf

[daniel3550]

Hi mon2

We are using internal flash of XUF216-512-FB236 - IS25LQ016B.

I used -v flag while generating bin file on an already-programmed device and a pristine device. There are some differences in the calls to libcompressor

_programmed_log.txt

libcompressor DoCompression_Compress took : 886ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-e882f2c2" -x xn "target-xn-v0-d26cb3d7" -o decompressor-89cbfe05
libcompressor validating decompressor decompressor-89cbfe05
libcompressor launching simulator decompressor-89cbfe05 --disable-syscalls --max-cycles 100000000

_pristine_log.txt

libcompressor DoCompression_Compress took : 555ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-23ccf155" -x xn "target-xn-v0-4d0f14f6" -o decompressor-41d4259d
libcompressor validating decompressor decompressor-41d4259d
libcompressor launching simulator decompressor-41d4259d --disable-syscalls --max-cycles 100000000

Also the spiinfo flag on xrun --io command is different.
_programmed_log.txt

XFlash_DeviceInfo::GetDeviceInfo_Hardware_IssueCompileCommand : xcc -Xmapper --dontenablesodlinks -Xmapper --wnoXN -x xc "spiinfo-ba4a3715" -x xn "target-xn-v0-d26cb3d7" -o "spiinfo-f234af87" -lquadflash -D xnPORT_SQI_CS0=PORT_SQI_CS -D xnPORT_SQI_SCLK0=PORT_SQI_SCLK -D xnPORT_SQI_SIO0=PORT_SQI_SIO
XFlash_Utils::BuildRunCommand : xrun --io spiinfo-f234af87

_pristine_log.txt

XFlash_DeviceInfo::GetDeviceInfo_Hardware_IssueCompileCommand : xcc -Xmapper --dontenablesodlinks -Xmapper --wnoXN -x xc "spiinfo-b7a4e13b" -x xn "target-xn-v0-4d0f14f6" -o "spiinfo-3c97a523" -lquadflash -D xnPORT_SQI_CS0=PORT_SQI_CS -D xnPORT_SQI_SCLK0=PORT_SQI_SCLK -D xnPORT_SQI_SIO0=PORT_SQI_SIO
XFlash_Utils::BuildRunCommand : xrun --io spiinfo-3c97a523

Full logs are attached.

I've read "Guidance-for-mass-production-programming-of-integrated-flash-in-xCORE-200_3.pdf". I don't see anything we're doing wrong from that document it's pretty straightforward.

Thanks for the help.

[daniel3550]

Something else I noticed. We are using design based on xCORE-200 multichannel audio platform. We are using firmware app_usb_aud_xk_216_mc. The xCORE-200 multichannel audio platform uses XE216-512-TQ128 (no internal flash), while our design uses XUF216-512-FB236 (with internal flash). We are still using xk-audio-216-mc.xn device file, which says the flash is external S25FL116K.

xk-audio-216-mc.xn

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"/>
    </Device>
  </ExternalDevices>

I'm not sure if that could cause an issue. After compiling I connect XTAG to our board and I can program or create binary file. I'm not sure if the XN file is used in either of these cases since the real device is connected.

[mon2]

My 2 bits (half a nibble) is that on a pristine device, the internal flash is NOT in QSPI mode as supplied from the factory. Using standard SPI serial commands, you can ENABLE the QSPI bit

Can you confirm this? Some time ago, I had posted some bit banging code to read out the QSPI register bit out of the flash using the XMOS StartKit.

Check BIT 6 of the STATUS REGISTER which is the QE bit.

You should be able to use the same source code to dump the pristine device to validate this thought.

[mon2]

Hi. Had some issues with this user forum yesterday and could not log back in and also missed your last post.

Yes, the XN file should match your true flash device for best results. Consider to create a simple project using the same CPU with internal flash as you are using and code up perhaps a simple LED blinky where you can monitor the results on your custom PCB. At the very least, you can use a test meter to review if the blinky code is working. Also be sure to review the XN file that is wizard generated using the XMOS toolchain and apply these changes to the audio IP you are reviewing in this thread.

It has been a while but there are differences in some of the commands between flash vendors that could be causing the chaos.

Upload the code to your custom PCB using the method you are testing but with the revised XN file - does that work for you? Also be sure that your target is the hardware and not the simulator. Please post your results.

[daniel3550]

Turns out the problem was WP# and HOLD# pins. These were not properly driven, so the internal flash was not responding.

The reason SPI programming would start working after programming a device with an XTAG was because the XTAG sets the non-volatile QE bit of the flash. When this bit is set WP# and HOLD# pins are used as IO2 and IO3.