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?
Quadflash Not found in 15.3 Topic is solved
-
- XCore Addict
- Posts: 219
- Joined: Tue Jan 17, 2017 9:25 pm
-
- New User
- Posts: 2
- Joined: Wed Jul 24, 2024 12:05 pm
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.
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.
-
- XCore Addict
- Posts: 219
- Joined: Tue Jan 17, 2017 9:25 pm
OK, thanks. I'll go about updating instances of 'fl_connectToDevice()' to `fl_connect()`.
-
- XCore Addict
- Posts: 219
- Joined: Tue Jan 17, 2017 9:25 pm
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.
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.
-
Verified
- Member
- Posts: 11
- Joined: Wed May 22, 2024 3:30 pm
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.
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
xmos software engineer
-
- XCore Addict
- Posts: 219
- Joined: Tue Jan 17, 2017 9:25 pm
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?
-
Verified
- Member++
- Posts: 19
- Joined: Thu Jan 10, 2019 6:07 pm
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
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
-
Verified
- Member++
- Posts: 19
- Joined: Thu Jan 10, 2019 6:07 pm
You may want to remove --verbose too.
-
- XCore Addict
- Posts: 219
- Joined: Tue Jan 17, 2017 9:25 pm
Thanks. Adding --force-xscope brings us back to the behavior we are accustomed to.
-
- XCore Addict
- Posts: 219
- Joined: Tue Jan 17, 2017 9:25 pm
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.
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.