DFU code stalling on board side

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
polica
Junior Member
Posts: 4
Joined: Wed Jul 31, 2019 12:19 am

DFU code stalling on board side

Postby polica » Thu Aug 08, 2019 1:06 am

We're using an XUF216-512-TQ128-C20 and we're trying to get the DFU functionality to work.
However it looks like something is going wrong on the boards side.

There is a loop in module_dfu/dfu.xc on line 297 that seems like it's
supposed to continue looping to check for DFU communication, but it
stops after executing just a few times.

I traced the problem to line 301 where USB_GetSetupPacket(...) is
called but never returns, which I narrowed down to a call to
XUD_GetSetupData in lib_usb/src/lowlevel/XUD_EpFuncs.S

Is there anything that can be done here?
Something wrong in a different part of the program maybe?
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sun Aug 11, 2019 1:10 am

rgilio
Active Member
Posts: 33
Joined: Wed Jul 03, 2019 1:01 am

Postby rgilio » Thu Aug 15, 2019 11:15 pm

We've referenced several forums posts but to no avail. We have been unable to get DFU working. We can get it to boot into DFU mode but all transfers don't work. Whenever an upload or download is performed, 0 bytes are transferred.
I've tried using other dfu programs such as dfu-tool and dfu-util. This is the output I get from "dfu-util"

Code: Select all

$ sudo dfu-util --download upgrade_image_2_0.bin -v
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
libusb: debug [libusb_get_device_list] 
libusb: debug [discovered_devs_append] need to increase capacity
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_config_descriptor] index 1
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_config_descriptor] index 1
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_endpoint] skipping descriptor 25
libusb: debug [parse_endpoint] skipping descriptor 25
libusb: debug [parse_endpoint] skipping descriptor 25
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_endpoint] skipping descriptor 30
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [parse_configuration] skipping descriptor 0xb
libusb: debug [parse_endpoint] skipping descriptor 25
libusb: debug [parse_endpoint] skipping descriptor ff
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
libusb: debug [libusb_open] open 1.55
libusb: debug [usbi_add_pollfd] add fd 9 events 4
libusb: debug [libusb_close] 
libusb: debug [usbi_remove_pollfd] remove fd 9
libusb: debug [libusb_get_device_descriptor] 
libusb: debug [libusb_get_config_descriptor] index 0
Opening DFU capable USB device...
libusb: debug [libusb_open] open 1.55
libusb: debug [usbi_add_pollfd] add fd 9 events 4
ID 20b1:0008
Run-time device DFU version 0110
Claiming USB DFU Interface...
libusb: debug [libusb_claim_interface] interface 0
Setting Alternate Setting #0 ...
libusb: debug [libusb_set_interface_alt_setting] interface 0 altsetting 0
Determining device status: libusb: debug [libusb_alloc_transfer] transfer 0x55d62ae62e00
libusb: debug [libusb_submit_transfer] transfer 0x55d62ae62e00
libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line)
libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
libusb: debug [handle_events] poll fds modified, reallocating
libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb: debug [handle_events] poll() returned 1
libusb: debug [reap_for_handle] urb type=2 status=0 transferred=6
libusb: debug [handle_control_completion] handling completion status 0
libusb: debug [disarm_timerfd] 
libusb: debug [usbi_handle_transfer_completion] transfer 0x55d62ae62e00 has callback 0x7fbd58622b30
libusb: debug [sync_transfer_cb] actual_length=6
libusb: debug [libusb_free_transfer] transfer 0x55d62ae62e00
state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download	[                         ]   0%            0 byteslibusb: debug [libusb_alloc_transfer] transfer 0x55d62ae54200
libusb: debug [libusb_submit_transfer] transfer 0x55d62ae54200
libusb: debug [add_to_flying_list] arm timerfd for timeout in 5000ms (first in line)
libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb: debug [handle_events] poll() returned 1
libusb: debug [reap_for_handle] urb type=2 status=-32 transferred=0
libusb: debug [handle_control_completion] handling completion status -32
libusb: debug [handle_control_completion] unsupported control request
libusb: debug [disarm_timerfd] 
libusb: debug [usbi_handle_transfer_completion] transfer 0x55d62ae54200 has callback 0x7fbd58622b30
libusb: debug [sync_transfer_cb] actual_length=0
libusb: debug [libusb_free_transfer] transfer 0x55d62ae54200
dfu-util: Error during download
libusb: debug [libusb_close] 
libusb: debug [usbi_remove_pollfd] remove fd 9
libusb: debug [libusb_exit] 
libusb: debug [libusb_exit] destroying default context
Here's my output when I use the xmosdfu tool

Code: Select all

sudo ./xmosdfu --download upgrade_image_2_0.bin -vvvv
VID = 0xbda, PID = 0x8153, BCDDevice: 0x3001
VID = 0xbda, PID = 0x8153, BCDDevice: 0x3000
VID = 0x424, PID = 0x5537, BCDDevice: 0x6080
VID = 0x1d6b, PID = 0x3, BCDDevice: 0x415
VID = 0x4d8, PID = 0xb29, BCDDevice: 0x2
VID = 0x424, PID = 0x2137, BCDDevice: 0x6080
VID = 0x413c, PID = 0x3016, BCDDevice: 0x2900
VID = 0xbda, PID = 0x4014, BCDDevice: 0x5
VID = 0x20b1, PID = 0xf7d4, BCDDevice: 0x1006
VID = 0x424, PID = 0x2137, BCDDevice: 0x6080
VID = 0x1d6b, PID = 0x2, BCDDevice: 0x415
VID = 0x1d6b, PID = 0x3, BCDDevice: 0x415
VID = 0x8087, PID = 0xa2b, BCDDevice: 0x10
VID = 0x1bcf, PID = 0x2b95, BCDDevice: 0x5605
VID = 0x20b1, PID = 0x8, BCDDevice: 0x1120
XMOS DFU application started - Interface 0 claimed
Detaching device from application mode.
Waiting for device to restart and enter DFU mode...
VID = 0xbda, PID = 0x8153, BCDDevice: 0x3001
VID = 0xbda, PID = 0x8153, BCDDevice: 0x3000
VID = 0x424, PID = 0x5537, BCDDevice: 0x6080
VID = 0x1d6b, PID = 0x3, BCDDevice: 0x415
VID = 0x4d8, PID = 0xb29, BCDDevice: 0x2
VID = 0x424, PID = 0x2137, BCDDevice: 0x6080
VID = 0x413c, PID = 0x3016, BCDDevice: 0x2900
VID = 0xbda, PID = 0x4014, BCDDevice: 0x5
VID = 0x20b1, PID = 0xf7d4, BCDDevice: 0x1006
VID = 0x424, PID = 0x2137, BCDDevice: 0x6080
VID = 0x1d6b, PID = 0x2, BCDDevice: 0x415
VID = 0x1d6b, PID = 0x3, BCDDevice: 0x415
VID = 0x8087, PID = 0xa2b, BCDDevice: 0x10
VID = 0x1bcf, PID = 0x2b95, BCDDevice: 0x5605
VID = 0x20b1, PID = 0x8, BCDDevice: 0x1120
... DFU firmware upgrade device opened
... Downloading image (upgrade_image_2_0.bin) to device
... Download complete
... Returning device to application mode
Unfortunately, it looks like the xmosdfu tool doesn't quite tell us what's going wrong. I'm also uncertain about the dfu-util tool displaying what's actually going wrong since I'm not sure if it could even interface properly with the device anyways but I figure it might provide some insight into what's happening. I also get two different and wrong results whenever I try to read the current image using the xmosdfu tool. Sometimes the output file just keeps getting a set of repeating lines forever until I force stop the program, the other case is that it returns that the file was uploaded just fine but the file on my system is 0 bytes.


I'm running on Ubuntu 18.04 for reference. I'm going to see if I can get this to work on Windows in the meanwhile, but we need this to work on Linux.
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Aug 15, 2019 11:28 pm

Hi. Not on Linux myself but the DFU-UTIL is not applicable for the XMOS devices.
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Aug 16, 2019 12:31 am

Hi. Please review this thread, test the ideas and update this thread:

viewtopic.php?f=26&t=6746&hilit=DFU+hex+editor
rgilio
Active Member
Posts: 33
Joined: Wed Jul 03, 2019 1:01 am

Postby rgilio » Fri Aug 16, 2019 11:20 pm

I went through the link posted above but still have been unsuccessful.
I've double checked my commands for creating the binary as well as comparing the binary on the device before and after running the tool but the flash doesn't seem to change.

I've made sure that the FLASH_MAX_UPGRADE flag doesn't exist.

Code: Select all

-DFLASH_MAX_UPGRADE_SIZE=64*1024 
I'm creating my update package with the collowing command:

Code: Select all

xflash --factory-version 14.3 --upgrade 2 app_usb_aud_mic_array_2i8o2.xe -o fw_3_5.bin
The filesize is about 43Kb so nothing too large. I then should be able to run the xmosdfu tool

Code: Select all

sudo ./xmosdfu --download fw_3_5.bin
However, the binary never seems to be flashed to the device despite the output

Code: Select all

... DFU firmware upgrade device opened
... Downloading image (fw_3_5.bin) to device
... Download complete
... Returning device to application mode
I'm unsure how to debug this any further as using the xtag debugger stops running when the xmosdfu tool puts the device into reset. If I have the device automatically start in DFU mode when launching the debugger, the xmosdfu tool spits out the following error:

Code: Select all

Error claiming interface 0
Another program or driver has claimed the interface
How do I debug this further? I am also starting to think that the application might not have access/permission to read/write from flash which is why it's not uploading or downloading anything with the xmosdfu utility but I'm not quite how I go about testing/verifying that. Any insight on this?
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Aug 16, 2019 11:23 pm

What does the following show? (added --verbose flag)

Code: Select all

xflash --factory-version 14.3 --verbose --upgrade 2 app_usb_aud_mic_array_2i8o2.xe -o fw_3_5.bin
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri Aug 16, 2019 11:33 pm

Also, can you use xflash to READ OUT the contents of your flash device -> then use any freeware hex editor to import the flash dump and confirm the structure of the flash memory?

The flash structure is detailed here:

viewtopic.php?t=5041

PS: We use the following hex editor in the lab - great tool:

https://mh-nexus.de/en/hxd/

Plan B (as we are mostly hardware guys) - desolder the flash memory chip -> solder onto your favorite break out board and read with an external flash reader to confirm what is inside the flash memory and compare against the above header structure. Do this before and after the above exercise to see at least the results. Unless mistaken, the flash should not be write protected.

Are you using 100% the same flash device that is defined by your flash specifications? If not, that could be an issue.

Is the XMOS toolchain able to store your code inside this flash device so that it works on each and every power up cycle? That will be a good start.

Moving forward, are you on XCORE-200 series CPU? If yes, then you are using the QSPI mode for the flash? If yes, is the flash you are using on the compatible list of QSPI flash devices? If not, you must create a custom definition file to inform the XFLASH tool on how to R/W to this flash in QSPI mode - also important on the details of the QSPI BIT. They are not always in the same location.

Never mind...you already stated XUF216-512-TQ128-C20 so the flash is INTERNAL to the device and is by ISSI.

You should be able to dump the contents of this internal flash to compare notes. Also could read out the QSPI bit. We posted some source code in this forum using the STARTKIT and standard SPI commands to R/W the QSPI bit of this flash device.
rgilio
Active Member
Posts: 33
Joined: Wed Jul 03, 2019 1:01 am

Postby rgilio » Fri Aug 16, 2019 11:46 pm

mon2 wrote:
Fri Aug 16, 2019 11:23 pm
What does the following show? (added --verbose flag)

Code: Select all

xflash --factory-version 14.3 --verbose --upgrade 2 app_usb_aud_mic_array_2i8o2.xe -o fw_3_5.bin
Here's the output

Code: Select all

XFlash_Application found _start :40000 on Node 0
XFlash_Application found _DoSyscall :41914 on Node 0
XFlash_Application found _DoException :400a4 on Node 0
XFlash_Application found _start :40000 on Node 0
XFlash_Application found _DoSyscall :474ac on Node 0
XFlash_Application found _DoException :400a4 on Node 0
XFlash_Application : Attempting to Compress Binary Data
libcompressor marker 1=149
libcompressor marker 2=181
libcompressor marker 3=165
libcompressor best marker length 3 2 2 
libcompressor best marker length 3 2 3 
libcompressor best marker length 3 2 4 
libcompressor best marker length 4 2 4 
libcompressor DoCompression_Compress took : 74ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-fc3ef51e" -x xn "target-xn-v2-038c24c6" -o decompressor-0d921fc9
libcompressor validating decompressor decompressor-0d921fc9
libcompressor launching simulator decompressor-0d921fc9 --disable-syscalls --max-cycles 100000000
libcompressor simulator starting @0x40000
libcompressor simulator terminate @0x7ff5a
libcompressor decompressor validated
XFlash_Application on Node : 0 compressed from : 10956 bytes to : 8000 bytes (26.98%)
libcompressor marker 1=219
libcompressor marker 2=227
libcompressor marker 3=126
libcompressor best marker length 3 2 2 
libcompressor best marker length 3 2 3 
libcompressor best marker length 3 2 4 
libcompressor best marker length 4 2 4 
libcompressor DoCompression_Compress took : 975ms
libcompressor compile command=xcc -nostartfiles -Xmapper --bootstyle=forsim -x assembler-with-cpp "decompressor-aca2b133" -x xn "target-xn-v2-038c24c6" -o decompressor-f6c56432
libcompressor validating decompressor decompressor-f6c56432
libcompressor launching simulator decompressor-f6c56432 --disable-syscalls --max-cycles 100000000
libcompressor simulator starting @0x40000
libcompressor simulator terminate @0x7ff5a
libcompressor decompressor validated
XFlash_Application on Node : 0 compressed from : 45052 bytes to : 31088 bytes (31%)
XFlash::DoXFlash
XFlash::DoImageProgramming
XFlash::GetDeviceInfo
XFlash_DeviceInfo::GetDeviceInfo_User
XFlash::BuildFlashBinaryFile
XFlash_Builder_S2L::BuildStage2Loaders Upgrade version 2
Stage2_SwitchSetup::Compile : xcc -c -march=xs2a -x assembler-with-cpp swstup-n0v2-2ccbf3e6 -o swstup-n0v2-c0eff6e5
Stage2_SwitchSetup::Compile : xcc -nostartfiles -Wno-bidirectional-buffered-port -Xmapper --first -Xmapper swstup-n0v2-c0eff6e5 -Xmapper --dontenablesodlinks -Xmapper --nochaninit -Xmapper --noinitialtidy -Xmapper --wno110 -Xmapper --wno226 -Xmapper --wnoXN -std=c99 -O2 -x xn "target-xn-v2-038c24c6" -x xc swstup-n0v2-b3f3c354 -lswitchsetup -o swstup-n0v2-d7177c45
XFlash_Builder_Image::BuildImages Upgrade version 2
XFlash_Builder_Image::BuildImageTable
  master node = 0
    node = 0
XFlash_Builder_Image::BuildImageTable num cores for image table = 2
XFlash_Builder_Image::CalculateBufferSize Starting calculation _total_image_size=0
XFlash_Builder_Image::CalculateBufferSize Add Image Header _total_image_size=34
XFlash_Builder_Image::CalculateBufferSize Add Switch Setup header _total_image_size=3c
XFlash_Builder_Image::CalculateBufferSize Add Per Core header _total_image_size=54
XFlash_Builder_Image::CalculateBufferSize_SwitchSetup _total_image_size=7ac
XFlash_Builder_Image::CalculateBufferSize_Application application size = 1f44 _total_image_size = 26f0
XFlash_Builder_Image::CalculateBufferSize_Application application size = 7974 _total_image_size = a064
XFlash_Builder_Image::BuildImageTable allocated image buffer size = a064
XFlash_Builder_Image::WriteBuffer_ImageHeader
XFlash_Builder_Image::WriteBuffer_SwitchSetup current switch setup table offset : 34
XFlash_Builder_Image::WriteBuffer_SwitchSetup current application data offset : 54
XFlash_Builder_Image::WriteBuffer_SwitchSetup size : 754
XFlash_Builder_Image::WriteBuffer_SwitchSetup aligned_size : 758
XFlash_Builder_Image::WriteBuffer_SwitchSetup init_vec_shift : 0
XFlash_Builder_Image::WriteBuffer_Application
XFlash_Builder_Image::WriteBuffer_Application for node : 0
XFlash_Builder_Image::WriteBuffer_Application for core : 0
XFlash_Builder_Image::WriteBuffer_Application current core table offset : 3c
XFlash_Builder_Image::WriteBuffer_Application current application data offset : 7ac
XFlash_Builder_Image::WriteBuffer_Application size : 1f40
XFlash_Builder_Image::WriteBuffer_Application aligned_size : 1f44
XFlash_Builder_Image::WriteBuffer_Application init_vec_shift : 0
XFlash_Builder_Image::WriteBuffer_Application chan end : 80020002
XFlash_Builder_Image::WriteBuffer_Application for core : 1
XFlash_Builder_Image::WriteBuffer_Application current core table offset : 48
XFlash_Builder_Image::WriteBuffer_Application current application data offset : 26f0
XFlash_Builder_Image::WriteBuffer_Application size : 7970
XFlash_Builder_Image::WriteBuffer_Application aligned_size : 7974
XFlash_Builder_Image::WriteBuffer_Application init_vec_shift : 0
XFlash_Builder_Image::WriteBuffer_Application chan end : 80030002
XFlash_Builder_Image::WriteBuffer_CRC
XFlash_Builder_Binary::BuildBinary
XFlash_Builder_Binary::CalculateBufferSize_Factory
XFlash_Builder_Binary::CalculateBufferSize_Factory : First User Sector offset = 0
XFlash_Builder_Binary::CalculateBufferSize_Upgrade
XFlash_Builder_Binary::CalculateBufferSize_Upgrade : Adding upgrade app (a064) a064
XFlash_Builder_Binary::CalculateBufferSize_Upgrade : Adding sector padding (9c) a100
XFlash_Builder_Binary::GetSearchLimitPadding : current size (a100) 0
XFlash_Builder_Binary::CalculateBufferSize_Data
XFlash_Builder_Binary::BuildBinary : Allocating buffer - a100
XFlash_Builder_Binary::GetSearchLimitPadding : current size (a100) 0
XFlash_Builder_Binary::WriteBufferToBinary : fw_3_5.bin
Also, I have used xlfash to READ OUT the contents of the flash device, both before and after the xmosdfu was used. There was no change in the binary output.
Unfortunately, HxD is not available on Linux (unless you compile with Wine, but not guaranteed to work) so I'm using an alternative hex program. I'll be honest, I've looked at that flash structure post but I wasn't sure how that related to what I was seeing in my flash dump. I was expecting to see the "0x1a551e5 for tools versions Tools12 and below; 0x0FF51DE for tools version Tools13 and above" hex values somewhere in here as a baseline but they didn't seem to exist. I may be confused on what 'offset' is in this regard, are we talking about 0x1 or 0x0 for offset 1? Pardon the confusion surrounding this.

Code: Select all

|00000000│ 7d 30 00 00 f3 37 00 09 ┊ 00 0b 00 00 00 00 02 00 │}000×70_┊0•0000•0│
│00000010│ 50 00 00 00 80 00 00 00 ┊ 00 00 00 00 00 00 00 00 │P000×000┊00000000│
│00000020│ 00 00 00 00 00 00 00 00 ┊ 00 00 00 00 00 00 00 00 │00000000┊00000000│
│*       │                         ┊                         │        ┊        │
│00000080│ 00 00 00 00 00 0f 04 77 ┊ 00 86 a0 87 1c 68 4c 6b │00000••w┊0××וhLk│
│00000090│ f1 0f fb 86 8a 4a 30 0f ┊ 0d 86 b2 04 81 00 0e 71 │ו×××J0•┊_×ו×0•q│
│000000a0│ f0 cd c8 19 d7 0f ef bd ┊ e0 0f 77 86 51 89 12 84 │××וו××┊וw×Qו×│
│000000b0│ da 9f ce 70 54 47 f7 0f ┊ 31 3d b4 86 04 77 1d ef │×××pTGו┊1=×וw•×│
│000000c0│ ce 71 40 0f b8 86 2c ef ┊ ce f1 3c 68 a3 8d 20 37 │×q@•××,×┊××<h×× 7│
│000000d0│ d5 ff ce 70 4d 60 44 47 ┊ 0f f1 53 0d 00 0f 78 f6 │×××pM`DG┊•×S_0•x×│
│000000e0│ 0f 71 0e 71 00 0f 82 06 ┊ 04 86 00 0f 88 c6 00 0f │•q•q0•×•┊•×0•××0•│
I'm unsure if Plan B is possible since I'm on an XUF board so the flash is internal (please correct me if I'm wrong or misunderstanding).
User avatar
mon2
XCore Legend
Posts: 1518
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Aug 17, 2019 2:45 am

Hi.

1) For hex editor tools on Linux:

https://www.tecmint.com/best-hex-editors-for-linux/

2) If possible, consider to test the same on a Windows box to determine the root cause. Then you can always return to Linux once this process is confirmed to be working. Same issues on Windows?

3) Try to erase the flash and read back the contents to confirm the flash is indeed being erased.

Code: Select all

xflash --erase-all --verbose --spi-spec IS25LQ016B 
What is the output from above?

Then proceed to read back the contents of this same flash and review the contents to confirm that the flash has been erased.

4) One concern I have is that the following thread, which is similar to your case, lists more details on the hardware and that the flash device is QSPI style yet your log does not offer this detail:

viewtopic.php?t=7141
XFlash::DoXFlash
XFlash::DoImageProgramming
XFlash::GetDeviceInfo
XFlash_DeviceInfo::GetDeviceInfo_Hardware
XFlash_DeviceInfo::GetDeviceInfo_Hardware_IssueCompileCommand : xcc -Xmapper --dontenablesodlinks -Xmapper --wnoXN -x xc "spiinfo-0fd69a7b" -x xn "target-xn-v0-9b4715b6" -o "spiinfo-aabdcc4a" -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 spiinfo-aabdcc4a
for this reason, consider to test on Windows and post your updates.

Do confirm that you have a valid XN file for this CPU that defines the QSPI mappings (which are internal but still need to be listed in the XN file). You can review the wizard generated file by creating an empty project and selecting this specific CPU as the target.

Who is online

Users browsing this forum: No registered users and 1 guest