DFU not working on XUF216-512 platform

If you have a simple question and just want an answer.
Post Reply
Dohny
Member++
Posts: 26
Joined: Tue Dec 03, 2013 6:57 pm

DFU not working on XUF216-512 platform

Post by Dohny »

Hello guys,

I'm struggling with DFU on our XMOS XUF216-512 platform running USB audio.

First I burn the factory image with 0x104000 boot partition size as:

xflash --factory test.xe --boot-partition-size 0x104000


Then I get whats in readout.bin which was read from the actual memory. It looks like there is just 76KB of code right at the beginning with some zero padding.

Then I create the upgrade binnary file. I changed the BCD version to higher version, build type to upgrade, rebuild, create binary upgrade 1:

xflash --factory-version 14.2 --upgrade 1 test_update.xe -o fw_0500.bin

Update the XMOS succesfully thru DFU, but the firmware that boots up is the old factory one and not the DFU update. Whats in the flash memory you can see in the readout_dfu_loaded.bin.
The upgrade firmware is loaded on top of the factory image, which is expected I guess.

And now this is the wierd part. My constraint check is this:

Constraint check for tile[0]:
Cores available: 8, used: 6 . OKAY
Timers available: 10, used: 8 . OKAY
Chanends available: 32, used: 19 . OKAY
Memory available: 262144, used: 46012 . OKAY
(Stack: 3500, Code: 31168, Data: 11344)
Constraints checks PASSED.
Constraint check for tile[1]:
Cores available: 8, used: 1 . OKAY
Timers available: 10, used: 1 . OKAY
Chanends available: 32, used: 2 . OKAY
Memory available: 262144, used: 104868 . OKAY
(Stack: 932, Code: 19928, Data: 84008)
Constraints checks PASSED.
Build Complete


There is just our little OLED routine on one tile1 first core for now. The reason for the 100KB RAM taken are pictures, fonts etc... When I don't start the tile 1 OLED core, then I get about 4KB of tile 1 RAM taken.
Now when I take that firmware with suspended tile 1 core and create the upgrade bin file the same way and send it over DFU the actual thing boots the new image and works correctly (obviously without the display as the oled tile 1 core is not running).

My first guess was that the bootloader partition is not big enough, I tried lot of different sizes, from 512K to all the 2MB of flash. Nothing worked.
I tried different versions of drivers, from 1.6, 2.23 to 3.38. Again, nothing. I tried playing with BCD, enabling/disabling DFU, nothing helped.

Any idea where could be the problem? Image always loads over DFU correctly, it is in the flash memory, but the old factory image boots up. Could it be the xmos interface that I created between the tiles that is (probably) not running when the tile1 OLED core is stopped?

Thank you very much for any help. Files are attached below.
Attachments
upgrade.zip
(166.17 KiB) Downloaded 311 times
upgrade.zip
(166.17 KiB) Downloaded 311 times


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. A few comments:

From the XFLASH Command-Line Manual:

1) the FACTORY IMAGE becomes write-protected in hardware. So when you program with your UPGRADE image, this FACTORY IMAGE is over-written with the UPGRADE image ? If the factory image continues to boot upon every reset, then the factory image is still present and active. Is this correct ? Confused on how the upgrade image is over writing the factory image yet the factory image is the one that is booting.

2) you can also pass a size parameter for the factory image programming. Consider to add this parameter to reserve enough space for the factory image and then the upgrade image will start after this end of image marker.
xe-file [size]
--factory xe-file [size]
Specifies xe-file as the factory image. If size is specified, padding is inserted to
make the space between the start of this image and the next image at least the
specified size. The default unit of size is “bytes;” the size can be postfixed with k
to specify a unit of kilobytes.
At most one factory image may by specified.
3) use the same xflash tool version as the compiler version used for your code development.

4) your CPU is the XUF version so the flash is internal. Is the boot partition value passed to the xflash tool suitable for the internal flash present in this CPU ?

5) Consider to use the --target parameter with the specific .XN file for your CPU and test again.

6) Apply the --verbose command when using the xflash tool and post your logs for additional review of the details.
--verbose Prints additional information about the program when loaded onto the target
system.
http://www.xcore.com/viewtopic.php?t=3530

http://www.xcore.com/viewtopic.php?t=3202
RitchRock
XCore Addict
Posts: 186
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

Did you find a solution to your problem? I'm facing the same issue. DFU seems to complete successfully, but the factory image is always the one loaded.
Dohny
Member++
Posts: 26
Joined: Tue Dec 03, 2013 6:57 pm

Post by Dohny »

Hi, not really. Seems to have something to do with Thesycon driver. Kinda works on Mac and old Thesycon drivers (1.6), but only kinda it seems...
RitchRock
XCore Addict
Posts: 186
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

I got DFU working reliably by commenting out -DFLASH_MAX_UPGRADE_SIZE=64*1024
Post Reply