Custom flash support in xTIMEcomposer Topic is solved

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
eez-open
Active Member
Posts: 60
Joined: Mon Oct 23, 2017 1:49 pm
Location: Croatia

Re: Custom flash support in xTIMEcomposer

Postby eez-open » Fri Feb 23, 2018 12:25 pm

Oops, this is something new, the command:

xflash --spi-read-id 9f --spi-spec Adesto.txt --target EEZ-XE216-512-EVAL --verbose

... returns:

XFlash_Options::ListDevices : xgdb --batch -q --ex listdevices devl-620171b7
XFlash::DoXFlash
XFlash::DoReadWriteErase
XFlash_Programmer_ReadDeviceID::ReadDeviceId
XFlash_Programmer_ReadDeviceID::GenerateSource
XFlash_SPI_DeviceId::IssueCompileCommand : xcc -Xmapper --dontenablesodlinks -Xmapper --wnoXN -x xc "sqi-944511c1" -x xn "/media/denis/SSD_256GB/BACKUP/EEZ/XMOS/Community_14.3.2/targets/EEZ-XE216-512-EVAL/EEZ-XE216-512-EVAL.xn" -o "sqi-719146a9" -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 sqi-719146a9
Response to SPI ID command on tile[0]: 0x0, 0x0, 0x0.
View Solution
User avatar
mon2
XCore Legend
Posts: 1848
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Feb 23, 2018 12:26 pm

Very nice. So this explains why xflash is complaining - the IDs are not matching. Please check your mux + flash + CPU wiring. Need to see the IDs being read correctly.
User avatar
eez-open
Active Member
Posts: 60
Joined: Mon Oct 23, 2017 1:49 pm
Location: Croatia

Postby eez-open » Fri Feb 23, 2018 12:30 pm

Hm, I can see now, I got in return three zeros instead of 1F8401. Wiring is looks good so far, but I cannot see what is happening on lines (my MSO with logic analyser stopped to work few days ago, and I need to send it to repair). Many thanks for this anyway.
User avatar
mon2
XCore Legend
Posts: 1848
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Feb 23, 2018 12:38 pm

I think you are close. Time permitting, no promises but will see if we can simulate this at work. Considering for us to test as-is with the XCORE-200 Explorer kit and then repeat after replacing with some random QSPI flash device.

If you are really ambitious - which you are :) You could apply some code that makes use of the LIBFLASH coding to perform your own custom SPI flash commands. That is, right now you are depending on pre-canned code from XMOS for the xflash. While that is ok, you will have more control if you use your own source code. We did this for our Startkit experiments. Wrote some simple code to R/W to the flash in SPI mode. For the reading of the IDs, the QSPI mode is not used. This test of using your own code will validate that the xflash is not to blame if the results are the same.

What we would do is, start with toggling each port pin linked to your flash - do they toggle ok? Say @ 1Hz. Ok. Continue.

Next use the SPI library to perform the read ID command. We can share our code from the Startkit but you will have to alter the ports for your XCORE-200 CPU.

Let me post this in a few minutes so you can try, if you wish. In the meantime, consider to validate the port pins toggle ok.

-----

Lacking the logic analyzer - would you have a meter around? Use slow pulse for the port pin testing @ 10hz or similar.
User avatar
mon2
XCore Legend
Posts: 1848
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Feb 23, 2018 12:52 pm

Found a very nice perfect appnote for this exercise. Go to xtimecomposer tool -> left side -> examples and download project AN00188. Does this example allow for reading anything from your flash? Suspecting it will fail if the IDs do not match during the flash open handle effort. Assuming your custom PCB will match the port pin definitions found on the Explorer Kit but you can change them here to suit. This is an independent test and open source tool for your flash device and PCB. With the tools you have, hard to tell if the .h file we messed with is being touched or not during the xflash tool run. We will check for this in a few hours when our office opens.
User avatar
eez-open
Active Member
Posts: 60
Joined: Mon Oct 23, 2017 1:49 pm
Location: Croatia

Postby eez-open » Fri Feb 23, 2018 12:54 pm

mon2 wrote:I think you are close. Time permitting, no promises but will see if we can simulate this at work. Considering for us to test as-is with the XCORE-200 Explorer kit and then repeat after replacing with some random QSPI flash device.

If you are really ambitious - which you are :) You could apply some code that makes use of the LIBFLASH coding to perform your own custom SPI flash commands. That is, right now you are depending on pre-canned code from XMOS for the xflash. While that is ok, you will have more control if you use your own source code. We did this for our Startkit experiments. Wrote some simple code to R/W to the flash in SPI mode. For the reading of the IDs, the QSPI mode is not used. This test of using your own code will validate that the xflash is not to blame if the results are the same.

What we would do is, start with toggling each port pin linked to your flash - do they toggle ok? Say @ 1Hz. Ok. Continue.
Ok, I'll try this and let you know. I still have an old analogue scope so I can measure easily repetitive signal.
mon2 wrote: Next use the SPI library to perform the read ID command. We can share our code from the Startkit but you will have to alter the ports for your XCORE-200 CPU.

Let me post this in a few minutes so you can try, if you wish. In the meantime, consider to validate the port pins toggle ok.
Yes please, that would be great!
User avatar
mon2
XCore Legend
Posts: 1848
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Feb 23, 2018 1:03 pm

Ok. Please see attached. It is a hacked up version of the XMOS SPI Master code example we used to dump / read / write / QE enable flash bits using a simple StartKit. The idea is the same for your project.

Your QSPI flash is able to understand the older and more basic SPI commands.

Using simple bit banging, SPI commands can be emulated. We used the XMOS supplied routines to take a blank flash from Digikey -> read out the IDs to verify our widget is working -> then performed the QE bit enable which BTW you will need to do if you want the flash to boot upon power up with your XCORE-200 CPU.

You will need to mod this code for your XCORE-200 CPU but very curious to know of the results, as always. Once at work, can try the same testing but have a busy day ahead to try to close an open project.

Will check around to see if there is a SPI Master using XCORE-200 but could not locate one earlier on the website...


Image



Image
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1848
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Feb 23, 2018 1:18 pm

After some more thoughts on this, the best solution may be to debug using bit-banged routines for a SPI master for your project. This way you can alter any portion of the code as desired. For now, the calls to the hidden xmos routines may not be the best to debug your case. If the called routines reject the pairing of the code and definition than back to square one.

Task is to use the port pins used by your Adesto Flash device and bit-bang them to offer the older SPI interface for your XCORE-200 CPU:

CS
CLK
MOSI
MISO

Then send and receive data / commands with your device to debug. Very interesting project. Will try to code up something but time permitting. Feel like a fireman at work putting out fires all the time. However, on topic as attempting to finish up some SPI routines using the STM32 processor (due to ultra low cost) - the STM32CubeMX made a mess of things using their wizard.
User avatar
eez-open
Active Member
Posts: 60
Joined: Mon Oct 23, 2017 1:49 pm
Location: Croatia

Postby eez-open » Fri Feb 23, 2018 1:39 pm

Great, I'll try what you sent, but for anything more on programming side I need assistance of my colleague who is not here today. But, I already managed to send 500 Hz signal to two 1-bit ports (CS and CLK) using the following code:

Code: Select all

#include <xs1.h>
#include <timer.h>

out port qspi_cs = XS1_PORT_1B;
out port qspi_clk = XS1_PORT_1C;

int main() {
    while(1)
    {
        qspi_clk <: 0;
        qspi_cs <: 0;
        delay_milliseconds(1); // delay
        qspi_clk <: 1;
        qspi_cs <: 1;
        delay_milliseconds(1); // delay
    }

return 0;
}
I got the correct signal on the flash side, on both boards: one that is with and another without muxes. I don't know how to make the same on 4-bit port :).
User avatar
eez-open
Active Member
Posts: 60
Joined: Mon Oct 23, 2017 1:49 pm
Location: Croatia

Postby eez-open » Fri Feb 23, 2018 1:51 pm

Ok, I found that sending on 4-bit port is actually the same as to the 1-bit (only value is 4-bits :). I can say that all signals comes to flash as expected. Therefore flash (two of them on two boards) or XMOS QSPI routine doesn't work properly. We'll see what will happen with bit-banging and your code.

Who is online

Users browsing this forum: No registered users and 7 guests