Quadflash Not found in 15.3 Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
RitchRock
XCore Addict
Posts: 219
Joined: Tue Jan 17, 2017 9:25 pm

Quadflash Not found in 15.3

Post by RitchRock »

Moving from 15.2.1 to 15.3.0 and upon build I'm getting the flash I am using as now an "undeclared identifier". (FL_QUADDEVICE_ISSI_IS25LP016D).

So I checked and notice that QuadSpecMacros.h no longer has any flash specs in it. What are we expected to do here and what is the purpose of this change in 15.3? Is it documented anywhere?
View Solution
Daz
New User
Posts: 2
Joined: Wed Jul 24, 2024 12:05 pm

Post by Daz »

It's usually unnecessary to provide a flash spec to libquadflash in 15.2.1 and 15.3 for most use cases. We implemented SFDP (JEDEC Serial Flash Discoverable Parameter) in 15.2 and then subsequently removed the provided flash specs in 15.3.

The motivation for removing the built-in flash specs is that the list is increasingly out of date, and a source of unpredictability / confusion as to when SFDP is used. The behaviour could vary moving between different devices according to which built-ins we provided. We'd also identified an error in one of them around the same time that the decision was taken which would've been avoided had the library primarily used SFDP. A small amount of memory is reclaimed as well by not storing the array in RAM for `fl_connect()`. All of the devices that were previously supported with a built-in flash spec are capable of SFDP.

The changes to libquadflash are documented in the tools manual under 'List of devices natively supported by libquadflash' and 'libquadflash API'. There's some new information under the XFLASH manual as well.

It's likely you can transition to `fl_connect()` which should support the IS25LP016D device by using SFDP to interrogate it.
RitchRock
XCore Addict
Posts: 219
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

OK, thanks. I'll go about updating instances of 'fl_connectToDevice()' to `fl_connect()`.
RitchRock
XCore Addict
Posts: 219
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

OK that worked, but our commands for xflash are broken now in 15.3.

In 15.2 everything worked fine:
1. I build a factory image like this with a data partition like:

xflash --factory app_XXXXX.xe --noinq --boot-partition-size 0x1FF000 --data data.bin -o app_XXXXX.bin --verbose

2. I program image to boards:

xflash --write-all app_XXXXX.bin --target-file system.xn --verbose

In 15.2 the output would show the sector writes and then stop after a while. In 15.3 its going through lots of hex values like 'Site 0 skip 0x000d0300.'. I have to kill it before it can finish.
User avatar
upav
Verified
Member
Posts: 11
Joined: Wed May 22, 2024 3:30 pm

Post by upav »

Hey, could you define what do you mean by broken?
So far it seems like it just gives you more logging than before (which I think is true for xflash in 15.3).
If you don't like it to cobble your terminal you can put --no-reporting as an option and see if it executes faster.
Pavel
xmos software engineer
RitchRock
XCore Addict
Posts: 219
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

In 15.2 it takes only a moment to flash with these commands, now after 10 minutes it doesn’t finish. That is what I mean by broken. Do I need to make a change with these commands for 15.3?
markp
Verified
Member++
Posts: 19
Joined: Thu Jan 10, 2019 6:07 pm

Post by markp »

So for 15.2 we tried to optimise "flash duration" using the XLINK connection to the XTAG. Which improves write speed. But we found it unreliable on some boards so for 15.3 we went back to JTAG.
But I am surprised it takes 10 minutes+.

Can you try adding " --force-xscope" to the xflash command line?
E.g.

xflash --force-xscope --write-all app_XXXXX.bin --target-file system.xn --verbose
markp
Verified
Member++
Posts: 19
Joined: Thu Jan 10, 2019 6:07 pm

Post by markp »

You may want to remove --verbose too.
RitchRock
XCore Addict
Posts: 219
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

Thanks. Adding --force-xscope brings us back to the behavior we are accustomed to.
RitchRock
XCore Addict
Posts: 219
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

Has anything changed with fl_startImageAdd in 15.3 or when using it with the XU316? My DFU task is hanging on this - result from this are always 1 and get stuck at Check Point B in the typical DFU loop below. I have not previously had an issue with this until moving to new tools / device..

The only thing I've changed is updating instances of 'fl_connectToDevice()' to `fl_connect()` as mentioned above.

Code: Select all

fl_BootImageInfo image;
                fl_BootImageInfo factory_image;

                int flashstatus = fl_getFactoryImage(image);

                if (flashstatus != 0)
                {
                    debug_printf("No factory image exists in flash\n");
                    DFU_STATUS = no_factory_image; // No factory image
                    return 0;
                }
                else
                {
                    flashstatus = fl_getNextBootImage(image);

                    if (flashstatus != 0)
                    {
                        // No upgrade image exists in flash
                        debug_printf("No upgrade image exists in flash\n");
                        debug_printf("Check Point A\n");
                    }

                    int result;

                    do
                    {
                        if (flashstatus != 0)
                        {
                            result = fl_startImageAdd(image, FLASH_MAX_UPGRADE_IMAGE_SIZE, 0);
                            debug_printf("Check Point B. result  = %d\n", result);
                        }
                        else
                        {
                            result = fl_startImageReplace(image, FLASH_MAX_UPGRADE_IMAGE_SIZE);
                            debug_printf("Check Point C. result  = %d\n", result);
                        }
                    } while (result > 0);
Last edited by RitchRock on Mon Jan 06, 2025 10:55 pm, edited 1 time in total.