DFU Hangs Topic is solved

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
RitchRock
XCore Addict
Posts: 162
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

I really appreciate the starting point here. I'm trying both OSX command line and Windows (Thesycon) DFU Uploader. Here is the output of the DFU CON:
DFU-CON1.JPG
But as I mentioned, the upgrade never changes from version 0.1.

I took a look at the binary before and after the upload as suggested and the flash looks to be identical before and after upgrade, so obviously the upgrade isn't getting written. I don't really see any match between the linked header and what I see in the binary editor (hex-view plugin in Atom). Perhaps I need to use a different binary editor? Please forgive my ignorance on this. Here are the first lines of what Atom shows:
Atom-Capture1.JPG
I double checked that IS25LQ016B flash is supported and yes it is. If I use XFLASH within time-composer, I do get a warning about the speed not being specified and that it is defaulting to 15.62MHz. In the QuadSpecMacros.h file it says my log2 clock divider is 3, so wouldn't that correspond to a speed of 16.67MHZ (using 100MHZ ref)? Would this cause an issue? I don't see this frequency listed as a valid argument for --quad-spi-clock, so I'm wondering why it is the default value.
You do not have the required permissions to view the files attached to this post.


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

Post by mon2 »

You can alter the speed for the flash access by using one of the supported parmeters posted here:

http://www.xcore.com/viewtopic.php?t=5874

Code: Select all

  --quad-spi-clock arg       Set the Quad SPI clock for the second stage
                             loader;
                             arg = <5MHz|6.25MHz|8.33MHz|12.5MHz|13.88MHz|15.62
                             MHz|17.85MHz|20.83MHz|25MHz|31.25MHz|41.67MHz|50MH
                             z>

Also, use the

Code: Select all

--verbose
flag with xflash and review the additional comment from the tool

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

Post by RitchRock »

mon2 wrote:You can alter the speed for the flash access by using one of the supported parmeters posted here:

http://www.xcore.com/viewtopic.php?t=5874

Code: Select all

  --quad-spi-clock arg       Set the Quad SPI clock for the second stage
                             loader;
                             arg = <5MHz|6.25MHz|8.33MHz|12.5MHz|13.88MHz|15.62
                             MHz|17.85MHz|20.83MHz|25MHz|31.25MHz|41.67MHz|50MH
                             z>

Also, use the

Code: Select all

--verbose
flag with xflash and review the additional comment from the tool

reference:
http://www.xcore.com/viewtopic.php?t=6340
Yes, that is what I am talking about in my post, however 16.67MHZ is not one of the supported frequencies, so I'm wondering why the default divider for IS25LQ016B is 3 and if it can be changed.
User avatar
infiniteimprobability
XCore Legend
Posts: 1124
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

Yes - you can add this to your customdefines.h to make the lib_quadflash library slow down. Note this is separate from any xflash settings over JTAG

Code: Select all

/* Slow down flash from 16.66 to 12.5MHz. See clock divider entry */
/* This array is otherwise indentical to FL_QUADDEVICE_ISSI_IS25LQ016B */
#define FL_QUADDEVICE_ISSI_IS25LQ016B_12_5MHZ \
{ \
    20,                     /* Enum value to identify the flashspec in a list */ \
    256,                    /* page size */ \
    8192,                   /* num pages */ \
    3,                      /* address size */ \
    4,                      /* log2 clock divider */                             \
    0x9F,                   /* QSPI_RDID */ \
    0,                      /* id dummy bytes */ \
    3,                      /* id size in bytes */ \
    0x9D4015,               /* device id */ \
    0x20,                   /* QSPI_SE */ \
    4096,                   /* Sector erase is always 4KB */ \
    0x06,                   /* QSPI_WREN */ \
    0x04,                   /* QSPI_WRDI */ \
    PROT_TYPE_NONE,         /* no protection */ \
    {{0,0},{0x00,0x00}},    /* QSPI_SP, QSPI_SU */ \
    0x02,                   /* QSPI_PP */ \
    0xEB,                   /* QSPI_READ_FAST */ \
    1,                      /* 1 read dummy byte */ \
    SECTOR_LAYOUT_REGULAR,  /* mad sectors */ \
    {4096,{0,{0}}},        /* regular sector sizes */ \
    0x05,                   /* QSPI_RDSR */ \
    0x01,                   /* QSPI_WRSR */ \
    0x01,                   /* QSPI_WIP_BIT_MASK */ \
}


#define DFU_FLASH_DEVICE    FL_QUADDEVICE_ISSI_IS25LQ016B_12_5MHZ
//:
RitchRock
XCore Addict
Posts: 162
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

I did get a couple errors in flashlib_user.c after I made this change. I took the suggested action and made the following modifications:

Code: Select all

#ifdef DFU_FLASH_DEVICE
/* Using specified flash device rather than all supported in tools */
fl_QuadDeviceSpec flash_devices[] = {DFU_FLASH_DEVICE};
//fl_DeviceSpec flash_devices[] = {DFU_FLASH_DEVICE};
#endif

.....

#ifdef DFU_FLASH_DEVICE
    result = fl_connectToDevice(&p_qflash, flash_devices, 1);
    //result = fl_connectToDevice(&p_flash, flash_devices, 1);
But still the same result - DFU finishes successfully, but I'm still at old firmware version. Wanted to see if this provides any clues..?
RitchRock
XCore Addict
Posts: 162
Joined: Tue Jan 17, 2017 9:25 pm

Post by RitchRock »

I got it working! After comparing files in a hex editor (I recommend HxD), I noticed my upgrade was starting, but looked to be possibly truncated.

I somehow missed this thread where infiniteimprobability points out that this define is only there to speed things up. I simply commented it out and voila, DFU now works.

Code: Select all

-DFLASH_MAX_UPGRADE_SIZE=64*1024 
I have large header files in my firmware for FIR coefficients, so I guess it wasn't making enough room for the upgrade image.
James Chan
New User
Posts: 2
Joined: Wed May 11, 2022 8:46 am

Post by James Chan »

Ritch,

I had exactly same issue. Thanks for the post, it helped a lot!

James
RitchRock wrote: Tue Jun 05, 2018 10:56 pm I got it working! After comparing files in a hex editor (I recommend HxD), I noticed my upgrade was starting, but looked to be possibly truncated.

I somehow missed this thread where infiniteimprobability points out that this define is only there to speed things up. I simply commented it out and voila, DFU now works.

Code: Select all

-DFLASH_MAX_UPGRADE_SIZE=64*1024 
I have large header files in my firmware for FIR coefficients, so I guess it wasn't making enough room for the upgrade image.