SPI Flash Partition Table

[PVS_Bram]

Hi everyone,

As recommend in this topic, I decided to implement updating the firmware for XMOS XU316 MCU using and ESP32 in the following way:

1. Reset the XU316 MCU by pulling the RST_N pin to the ground. (This prevents communication to the QSPI Flash chip)
2. Use the SPI interface on the ESP32 to write the binary image to the QSPI Flash Memory According to the, I assume, specifications provided in the XU316 Datasheet: 9
   • Program size and CRC as LSB first.
   • Followed by each byte of the binary image as LSB Nibble first.
3. Stop pulling the RST_N pin to the ground. Allowing the device to restart.

The problem I am running into is how exactly the flash memory is partitioned or where exactly in the memory the binary file should be written too. I found the libflash API which supports many interesting features (get boot image, add image, image version, etc.) and would have been ideal! Sadly the source code for this exact library is not available, as far as I could tell. And I can't find a partition table for the flash anywhere.

Is there any application note/implementation available that shows how the data should be written to the flash when not using another XMOS device to update the firmware?

Kind regards.

Bram

[CousinItt]

Maybe this will help:

https://www.xmos.com/documentation/XM-0 ... flash.html

[PVS_Bram]

Maybe this will help:

https://www.xmos.com/documentation/XM-0 ... flash.html

Thanks for the quick reply! I came across this document and this indeed describes vaguely how the flash should work. But just like the other links from my original question, it never describes actual locations in the memory. The program uses the functions from the flash API to determine the locations in flash memory. The source code from this flash API is not available which is why I can't determine how these functions work.

The flash format diagram shows the Flash loader and Factory Image, but does not show actual addresses or how to determine them without the Flash API library.

[CousinItt]

I would have thought the partitions are packed, so the position of each one (apart from the first) is variable depending on the partition size. Can you inspect the fl_BootImageInfo structure to determine how big a partition is? It would then be just a matter of adding on the size of each partition to determine the position of the next one. [edit] I should say image rather than partition. The terminology can vary. [/edit]

[fabriceo]

Hi PVS_Bram,

so basically you plan to write the QSPI flash by yourself with 6 pins connected to the ESP32 in parallel of the xmos chip, right ?
this is probably OK if you use a chip like 74AVC4TD245 to separate the flow between the xmos and esp32.
Still this is not what I would recommend : as there are many IO pins on the xmos you could connect the ESP32 in SPI to the xmos (clk,mosi,miso), create some protocole in between in order to download the bin file in xmos ram, and then have a routine in the xmos that will just write this binary image record by using image_write from libquadflash .

but ok. if you pursue in your direction, then as far as I understand how the xmos xflash tools works, it just erase all the flash with fl_eraseAll() and write the binary file page by page (256byte) to the flash with fl_writePage().
so you just have to do the same on the esp32. To create the binary file just use the xflash utility command line.

regarding the image size and crc you mentioned, this is completely different. this is used when you boot the xmos in mode 010 or 011 and then the SPI flow from say esp32 is loaded in xmos ram only. this is using a routine which is in xmos rom and then the rst pin must not be 0 !

hope this helps

[fabriceo]

and if you want t know more on the binary structure and how to play with the images in the boot partition, then you can see the old code available here:
https://github.com/xcore/sc_flash/tree/ ... dule_flash

but it is no more open source and we don't know if xmos has made important changes to this

if finally you want to upload the image in ram as part of the boot procedure for mode 010 and 011, here is an old but certainly good code example where you can see the size/crc story:
https://github.com/xcore/sw_spi_slave_b ... ree/master