Using ESP8266/32 to write Flash

Non-technical related questions should go here.
User avatar
xaerox
Active Member
Posts: 36
Joined: Thu Apr 30, 2015 6:12 pm

Using ESP8266/32 to write Flash

Postby xaerox » Tue Jan 16, 2018 1:13 am

Hello everybody,
I've planned connecting an ESP8266 or ESP32 to my XMOS-Project. The communication between both MCUs would
be implemented using I2C.
One other feature, which I want to implement is: Writing new Firmware-Updates directly via WiFi/Internet.
So the ESP-Module will receive the new firmware and store it into XMOS-flash directly.
My question is: Is it possible, to use an SPI Master (by resetting the XMOS-Chip) for writing the flash directly?
Or should I use the I2C Communication between the two chips and the Xmos itself receives firmware file from ESP Module and store it to flash.

I hope you understand my problem. The XMOS-flash is connected via QSPI. I've not seen, that the ESP8266 also supports QSPI (I just see the MISO and MOSI wires).

Best Regards,
Thomas
User avatar
infiniteimprobability
XCore Legend
Posts: 1108
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Tue Jan 16, 2018 6:44 pm

Hmm, well you can of course hold xmos in reset and directly control the QSPI lines but you will need QPSI support (at least bit banged) in the ESP and also you need to be wary of SI with stubs on the lines (particularly clock).

Alternatively you could use the flashlib API under say, slave i2c control. We do that for DFU in the vocalfusion reference design for I2C and for USB in the usb audio reference design which you could use as an example. The flashlib API provides support for factory/upgrade images etc.
User avatar
xaerox
Active Member
Posts: 36
Joined: Thu Apr 30, 2015 6:12 pm

Postby xaerox » Wed Jan 17, 2018 2:22 pm

Thank you infiniteimprobability!
So the ESP only supports SPI (not QSPI) for connecting another devices. It needs the QSPI Port for its own flash.

At least I should use your second recommendation. I think this is simplier to realize to my project.
Another question to this problem:
There can be a communication via I2C between these two devices. But for the second way for DFU means, that the SPI-Port on ESP is free.
Should I use SPI instead of I2C?
It's planned, to send simple chars between XMOS ESP like simple commands for connection to the network. Otherwise the ESP will send the .bin File (am I'm right?) to XMOS, where the XMOS uses flashlib storing this new firmware-file on flash.

And can I just build the factory image in XMOS Command Tools and send it directly to XMOS? I should do some research for it.

Best, Thomas
User avatar
infiniteimprobability
XCore Legend
Posts: 1108
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Wed Jan 17, 2018 4:46 pm

You could use SPI for sure. We have SPI master and SPI slave libraries.

I will say this is a reasonable amount of work, although not too difficult. You generally need a layer on top of quadflashlib.h API and something to decode SPI commands. Also, SPI has no throttling mechanism so you may need the host (ESP) to send commands and then poll for completion. All doable stuff but you need to get your head around the quadflashlib.h API and devise a suitable protocol.

But in general sending a binary file (probably one page at a time so you don't have a huge RAM allocation) would be fine.

You can prepare the xmos binary file (complete with second stage bootloader etc.) by using xflash with the opts -o <binfile.bin> so that bit is easy.
User avatar
xaerox
Active Member
Posts: 36
Joined: Thu Apr 30, 2015 6:12 pm

Postby xaerox » Mon Jan 22, 2018 2:59 pm

I think the best way is to write the qspi flash directly from esp8266. But it only has spi-master. Not qspi.
So is it possible writing the flash page-wise which xmos can read after reset?
The problem would be, that quad enable should be activated. Is it possible, to activate QE through the spi master from ESP? I read about setting a Bit to 1. But which bit? Which address?
I have to learn more about spi flashes.
Best, Thomas
User avatar
infiniteimprobability
XCore Legend
Posts: 1108
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Mon Jan 22, 2018 3:45 pm

Actually - most QSPI can work in SPI mode. So I think that would make things a lot easier. And, there's no real need to boot XMOS from QSPI either. SPI is perfectly fine if you can wait a little longer (it will still only be a few 100ms or so depending on image size).

Programming the device while XMOS is in reset is also fine. It's a standard production programming technique. You will need to be careful on the SPI clock pin though. If you have unterminated stubs more than about 5mm long the clock reflections may cause boot issues.

I'm afraid I don't know a lot about QSPI devices and modes - it all is handled by the XMOS tools normally.
User avatar
mon2
XCore Legend
Posts: 1230
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Jan 22, 2018 5:50 pm

The problem would be, that quad enable should be activated. Is it possible, to activate QE through the spi master from ESP?


Yes. Performing this task is via the use of standard SPI commands.

I read about setting a Bit to 1. But which bit? Which address?


This is dependent on the part number and flash vendor you will actually use. Each respective datasheet will offer this detail on how to enable the QSPI mode or other variant of the enhanced modes. There are some common features across vendors and then there are further speed enhancements to separate one flash vendor from another. For example, all vendors offer standard SPI commands which use standard SPI format to perform a function. After which the response from the flash device may be in QSPI mode. That is, for each clock cycle, 4 bits are emitted by the flash device for which you are required to capture and reformat into the proper format. The intent is to allow you to save time since in a single clock cycle, you are extract 4 bits of information.

Now some flash vendors are offering QSPI commands in which, like the response, you can spit out of your QSPI master code, the traditional commands which would have taken additional clock cycles to pipe into the flash, now can be performed using QSPI mode. So, in a single clock cycle, you are piping from your QSPI master to the flash device, 4 bits till finished. The datasheet for the QSPI flash will document all the gory details on what is required.

Here is a snippet of some code we wrote for the StartKit to enable the QSPI mode of a flash device - target was the same flash device as present on the Startkit location and for the XRHA-2HP processor:


Image


Image

So for the above code, the end user was required to remove the SMD flash device off the Startkit -> solder in a blank flash device -> program the flash with the XRHA-2HP firmware using standard SPI commands (slow but required since the Startkit is wired for standard SPI mode and NOT QSPI mode) -> finally run the above code to enable the QSPI bit for the device we selected from ISSI. Then remove the SMD part and solder and use onto a XRHA-2HP based design.

It is very important to note that once the QSPI bit is enabled, do not park the QSPI lines to the wrong states (ie. hard strapped to ground or hard strapped to +3v3) else you stand a good chance to blow the drivers inside the flash device. That is, when you are using the QSPI mode, the QSPI pins must be free to be able to drive their outputs to the host CPU and not strapped to ground / +3v3 rails !!!

Some vendors use rather awkward register combinations to enable their QSPI modes but each is very possible to support using simple SPI commands.

ISSI likes to use Bit 6 for the QE bit and this configuration is non-volatile. Once set, you are good to go. However, if you perform a CHIP ERASE, the QE bit will reset to 0 (going from memory here but do confirm). Also, some suppliers offer to sell their flash devices with the QE bit already enabled from the factory so that is an option you may wish to consider.

Hope this helps.
User avatar
xaerox
Active Member
Posts: 36
Joined: Thu Apr 30, 2015 6:12 pm

Postby xaerox » Wed Jan 24, 2018 5:46 pm

Thank you infiniteimprobability and mon2!
I didn't know, that XMOS can boot from SPI Flash instead of QSPI. That would be the simplest solution and sufficient for our project.
So I want to tell more about my purposes.

I want to design a new PCB where an XMOS, ESP-WiFi-Module and IS25LP080D Flash are connected together with as short lines as possible. Thank you infiniteimprobability for the information with the clock. Maybe I could use an small resistor in series for avoiding reflections.

The XMOS and ESP are communicating via I2C. So I can control XMOS via WiFi. For the Firmware-Update-Task, the ESP would set the XMOS chip into reset mode for writing the flash. After writing the new firmware to the flash the xmos boots from flash with new firmware.

I just see one more problem now: while the XMOS chip boots from flash, the lines between flash and ESP should be disconnected. So the ESP SPI-pins should be in floating mode. Is it possible to use the SPI-Pins on ESP as inputs after writing the flash sucessfully? So the ESP should not interrupt the boot procedure of the xmos chip.

What do you think?
User avatar
mon2
XCore Legend
Posts: 1230
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Wed Jan 24, 2018 5:57 pm

Consider to use a FET based MUX that will allow you to steer the flash interface lines to either the XMOS processor or the ESP8266 / ESP32 CPU pins. Why a FET version? FET versions do not care about the direction of the data flow - they behave like an analog switch so this eases the design.

For example:

http://www.ti.com/lit/ds/symlink/sn74cb3q3257.pdf

Be sure to review upon power up, the XMOS CPU must have access to the flash device so it can boot. Only after you perform some special ESPxx sequence of over the air commands, should this MUX steer towards the ESPxx CPU and at the same time, park the XMOS CPU into reset.

You could further extend all of the above by applying some small footprint pads to allow you to assert an external SPI programmer to do the same. That is, once you dock this special cable, allow for the mux to perhaps DISABLE so that the factory programming cable can assert the SPI lines to reflash the target flash. Best to walk through the steps and be sure you have a work around - ie. once you receive the assembled PCBs from your assembly shop -> how to program the blank flash device? What if the flash device is corrupted and XMOS does not boot? How will you correct such corrupted flash when out in the field? and so on...

That is the approach we would consider.
User avatar
xaerox
Active Member
Posts: 36
Joined: Thu Apr 30, 2015 6:12 pm

Postby xaerox » Wed Jan 24, 2018 7:07 pm

Wow that sounds like a real nice solution!
Of course I'm applying some pads for external access to the flash in my prototype. The first start of the board, the ESP will be activated first and hold the XMOS in Reset.
So in production later, only the ESP will be programmed.
After programming the ESP and restarting the board, the ESP is in firmware installation mode. So I can transfer the firmware over the air and the ESP writes the pages to the flash. After these procedures the FET based MUX will switch the lines to XMOS.
That means, the MUX connects the flash to ESP at first run.
Thank you very much for your help!
Now I have some knowledge and ideas for designing the new prototype!
You're the best!
Thomas

Who is online

Users browsing this forum: No registered users and 6 guests