xCORE-200 USB Audio Design Advisory - Integrated flash change

[MyKeys]

Hi guys,

I'd like some clarification on this flash change design advisory as I have multiple products to support out in the field.

There seems to be 2 parts to this advisory:

1. Programming tool (xFlash) must know about the new flash device.
2. Existing firmware must be modified to know about the new flash for DFU/flash access etc.

The first issue is easily resolved by using xFlash from XTC v14.4.1. This seems the safest approach as knowing which revision device is being programmed doesn't matter as the tool supports both?
The second issue can be resolved in 2 ways:

Adding the new flash spec in source for the quad flash library and still building with the older tools version.
OR
Re-building with the latest tools (BUILD_FLAGS = -lquadflash should use the updated library supplied with the tools)?

As this only affects xCore200 devices which are only supported in v14+ tools, I don't need to be too worried about firmware out in the field as v14 binary DFU images will always be compatible?

Is there anything I may have missed?

Thanks for any help,
Mike.

[mon2]

My recommendation is

Re-building with the latest tools (BUILD_FLAGS = -lquadflash should use the updated library supplied with the tools)?

So that you are not a victim of the dfu bug that causes the new flash image to be corrupted and then the dfu loader will revert to run the factory image. At that stage, the end customer can no longer perform field upgrades. Search for the thread discussing this bug on a product from SMSL (Shenzhen) for more details.

[MyKeys]

Thanks mon2.

That SMSL upgrade fiasco sounds horrendous and definitely something I would want to avoid at all costs!

It's not quite clear to me how that issue has occurred?
How can a factory image allow a DFU upgrade to work once and then subsequent upgrades fail.
I understand that a corrupted upgrade image will result in the factory image loading due to crc check fail, but wouldn't a second attempt (with a good image) replace the corrupted upgrade image?

Or did the factory perhaps program a factory image (that doesn't like the new flash) along with a good upgrade image?

Mike.

[mon2]

The issue is documented here

(See below)

In summary, use the latest compiler with the latest flash library to circumvent this issue.

The issue is that in the process of the next upgrade, the current image is partially erased. Partially erased due to a header being found in the current image that the bootloader then deems to be a valid image. So now you have a corrupted image due to a partial erase and now the bootloader no longer permits the upgrade and reverts back to the factory image. Catch-22 that then requires return to factory for a full flash erase with JTAG or external hardware reflash.

Tools-Advisory_-Invalid-boot-image-returned-in-libflash-and-libquadflash_1.0 (1).pdf

[MyKeys]

Yikes, I'm glad I asked.
I had completely missed that advisory and we definitely have some old products in the field built with earlier versions.

Thank you!

[leobodnar]

I got a confusing email from XMOS:

URGENT ACTION REQUIRED

To Whom It May Concern,

We are notifying you of a Part Number Change that affects the XMOS xcore-200 devices with embedded flash memory. This includes all part numbers that start with XEF2, XUF2 and XLF2.

Memory supplier ISSI has die-shrunk their flash memory which is integrated into these devices. The replacement flash is a form, fit and function equivalent replacement.

However, you need to be aware that they need to modify the firmware loaded onto the embedded memory in the xcore-200 processor to recognise the new flash device.
It is essential that our customers who have implemented designs based on the XMOS USB Audio 2.0 reference software are made aware that existing firmware should not be downloaded onto any of the new part numbered devices. Using old firmware on new devices will render devices incapable of receiving any subsequent in-field update. The required changes are forwards compatible and should be enacted immediately.

The Product Change Notice and accompanying Design Advisory can be accessed here (trackable personalised link). Please contact your XMOS sales representative if you have any queries. Alternatively, you can contact us here (another trackable personalised link).

Please can you confirm receipt of this email and where appropriate, please acknowledge the fact that the design change will be implemented.

Kind regards,
Director of Sales EMEA, Xmos Ltd

I have a lot of questions.
Who are they in "they need to modify the firmware"?
Does "existing firmware" mean "legacy firmware" or does it also include current firmware.
Why does it only affect XMOS USB Audio 2.0 reference software?
Why do I have to acknowledge the fact that I will be making changes in my code?

Leo

[MyKeys]

Who are they in "they need to modify the firmware"?

They = Whoever is responsible for the firmware.

Does "existing firmware" mean "legacy firmware" or does it also include current firmware.

All firmware destined for the new A revision devices.

Why does it only affect XMOS USB Audio 2.0 reference software?

It doesn't, but USB Audio 2.0 reference software has DFU and so needs extra care.

Mike.

[MyKeys]

Looking at 14.4.1 tools I see the xn files have been updated to specify flash device:

Code: Select all

<Device NodeId="0" Tile="0" Class="SQIFlash" Name="bootFlash" Type="S25LQ016B" PageSize="256" SectorSize="4096" NumPages="8192">

S25LQ016B = old integrated flash code
S25LP016D = new revision A device flash code?

Surely I don't need to deal with different firmware for each device revision?

This seems very confusing.

I'd have hoped the process I listed initially would work for both revisions without specifying flash fitted.

Thanks,
Mike.