This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

eZDSP 5505 EEPROM programmer

Hi,

 

I am using eZDSP EEPROM programmer with hex55.exe version 4.3.5. The flash.bin generated by the hex55 is programmed using programmer_USBKey.out and everything was working fine so far. But recently the code size has increased to 65476 (still less than 64K) and the programmer does not give the programming complete message. Let me know how to solve this problem..also please give the link to the programmer sources if it is available.

 

Regards,

Nandan

Zipytrove, Bangalore

  • Hi Nandakumar,

    Sorry for the delay. Just for clarity are you using the C5515 eZdsp or the VC5505 eZdsp?

    The VC5505 eZdsp has 64KB of EEPROM space, and  65476 bytes may be over its capacity depending on how efficiently it is stored in that memory. I will investigate.

    Alternately, the C5515 eZdsp has a 4MB of NOR Flash for storing programs, which is more than plenty.

    We are in the process of releasing the source for the programmer.

    Regards,
    Mark

  • We are using VC5505 eZdsp, also it will be good if there can be some progress indicator and also if there are errors inform the user about it. We are using this programmer for production setup and it is hard without any indication.

  • Nandakumar,

    When I attempt to burn a .bin file of size 68KB, which is larger than the 64KB EEPROM, the programmer utility still prints "Programming Complete".

    We are preparing the programmer_USBKey project for open-source release, but in the mean time let me send you the source code.

    Please send your email address to me at so I can email you the project source.

    Thanks,
    Mark

  •  

    Hi guys,

    I realize that his key problem is too large of a file (68K) into the eeprom (64K),

    bu also the programmer utility realeased has a problem with file sizes as well.

     

    in the code reased by Digital spectrum which has the flash utility code in it

    http://support.spectrumdigital.com/boards/usbstk5505/revb/files/USBSTK5505_Demo.zip

    there is a section which read in the spi_rom_test.c file

    //----------------------

        /* Initialize the SPI interface */
        spirom_init( );

        /* Write to spirom */
        printf("Writing file...\r\n");
        for ( i = 0 ; i < 149 ; i++ )
        {
            /* Write a page */
            spirom_write(  (0x18000 + (i * spirom_PAGESIZE)), i * spirom_PAGESIZE, spirom_PAGESIZE );
        }

    //------------------------------------

    the spirom_PAGESIZE is 32 bytes and the loop only write 149 blocks

    149*32= 4768, either words or bytes depending on how the spirom_write routine talks to the eeprom.

    If your eeprom writing routine utility is this code then it needs to be fixed as it will not write anymore than  5K

    (this is the problem which I am running into)

     

    Also this program blindly dumps the file into :

    // Setup pointer in RAM for temporary storage of data
        ramPtr = (Uint8 *)  0x18000;

     

    I am re-writing parts of this program

    1) use the actual file size to determine how many 32 byte/word blocks to write (a fixed 149 blocks is just not sufficient)

    2) to read in and process limited size chunks (around 16K) how many ever 16K chunks are needed to program the whole file  (keeps processor from running out of ram)

    3) fix the verify also to use proper number of bytes

    4) create a fixed buffer to temp store the 16K chunks into instead of blinly writing into ram

     

    I am more than happy to send in my edit when I finish

    (I just found the problem last night around 1AM, and intend on writing the code tonight)

     

    Since the code that will be modified is only the spirom_test.c file, I will drop the source code here tomorrow.

     

    Also in trying to figure out this problem, I see other people complaining about not being able to run/flash the code properly, this may cover other complaints.

    In some of the solutions I see people pointing fingers at the lilnker files, the debugger Gel files, but it it more than likely that they are using this code

    and it is just lacking in some respects.

    Don't mis-understand, me it is a fine piece of code for a demo, but it was written just as that, and did not take into account the true file.

    it's only about 15 lines of changes that will take to fix this.

     

    Also, Mark, is it possible to get a copy of the source for the Hex55 utility?

     

    Best of regards

    Micah Wilson