C5515 eZdsp - Write to NOR Flash fails after 8192 bytes

Hello Robert,

Have you tried running the norflash test from the Spectrum Digital Demos? Run the nor_writer after that program completes and see if it works then... I will need to look into why the nor_writer did not program your whole flash, but if that fixes it, I may be onto something.

Regards,
Mark

One thing to watch out for...

There are three supported boot table formats 5510:1, 5510:2 and 5505.  Those values may be given as the argument to the hex55 -v option.  Any other value used for -v selects the 5510:2.  So if you are really saying -v5515 to hex55, you are getting boot format 5510:2.

I know nothing about the nor_writer program so that may be OK, but my guess is that it expects a 5505 format boot table. But then, nor_writer probably checks the format enough to know whether it is acceptable or not, so perhaps your "-v5515" was just a typo in your message.

I had read an earlier message about flashing the EEPROM for the 5505 eZdsp, where they used the -v5505 option with hex55, so I extrapolated to -v5515 ;)  Based on the comments, though, I removed the -v option altogether, but nor_writer still failed at the same point.

From what I see, nor_writer is simply (at a high level): reading in the file to a location in RAM, initializing, erasing and writing the FLASH, and then doing a read and compare.  So it may not be doing any format checking.  But I never get past the write portion.

Would the map file output of the hex55 run give any clues, per the cut and paste of it below?  I get the feeling it may be missing some key sections!

Thanks,

Robert

********************************************************************************
TMS320C55x Hex Converter v4.3.5
********************************************************************************

INPUT FILE NAME: <c55.out>
OUTPUT FORMAT: Extended Tektronix

PHYSICAL MEMORY PARAMETERS
Default data width : 8
Default memory width : 8
Default output width : 8

BOOT LOADER PARAMETERS
Table Type: SERIAL PORT (McBSP 8 bit Mode)
Entry Point: 0x0002475a


OUTPUT TRANSLATION MAP
--------------------------------------------------------------------------------
00000000..00ffffff Page=0 Memory Width=8 ROM Width=8
--------------------------------------------------------------------------------
OUTPUT FILES: c55.hex [b0..b7]

CONTENTS: 00000000..00004ea7 BOOT TABLE
.cinit : dest=00040240 size=00000100 width=00000001
vectors : dest=0004fe00 size=00000100 width=00000001
.text : dest=00020000 size=0000487e width=00000001
.const.1 : dest=00005598 size=00000202 width=00000001
.const.2 : dest=0000579c size=000000f6 width=00000001
.const.3 : dest=00005894 size=00000072 width=00000001
.const.4 : dest=00005908 size=0000007c width=00000001

--------------------------------------------------------------------------------
00000000..00ffffff Page=1 Memory Width=8 ROM Width=8 "*DEFAULT PAGE 1*"
--------------------------------------------------------------------------------
  NO CONTENTS

Here is the output of the norflash test Mark.  Looks happy!  And the attempt at nor_writer after failed.  I retried the same sequence again, with same result (norflash test pass, nor_writer fail).

Thanks,

Robert

-----------------------------------------------------------------------------------

EXBUSSEL = 5000
01 Testing NOR Flash...
This test writes a 1024-byte long pattern every FLASH_PAGESIZE = 0x20000 bytes.
Manufacture ID is: 0x01
Device ID is : 0xf9
Erasing Sectors containing pages.
Writing Flash pattern
Reading Flash pattern
Erasing 1st Flash page
PASS

***ALL Tests Passed***

Spectrum Digital provided an update that resolved this problem:

http://support.spectrumdigital.com/boards/usbstk5515/reva/

When attempting to use nor_writer.out, as provided by Spectrum Digital, it hung after reading a little over 32,768 bytes of my .bin file.  [I observed this with Process Monitor from www.sysinternals.com.]

I have downloaded the latest nor_writer code and executable from Spectrum Digital's page

http://support.spectrumdigital.com/boards/usbstk5515/reva/.

Both

http://support.spectrumdigital.com/boards/usbstk5515/reva/files/usbstk5515_BSL_RevA.zip

and

http://support.spectrumdigital.com/boards/usbstk5515/reva/files/usbstk1151_Demo_RevA.zip

contain a project named "nor_writer," with source code and compiled nor_writer.out both dated 6/22/2010.

The problem is obvious.  norflash_writer.c contains the code:

   Uint16 tx[0x4000];
   Uint16 rx[0x4000];
   ...

       ramPtr = &tx[0];
   ...
       if (fileSize != fread(ramPtr, 1, fileSize, fPtr)) // Read file to ram and check if read properly

Can you say "buffer overrun?"

0x4000 = 16,384 array entries (filled by fread( ) with one byte per entry).  The only reason it didn't crash after 16,384 bytes is because tx[] is immediately followed in memory by rx[], so it overran into the rx[] buffer before stepping on its own executable code.  Was this written as a 4th grade science project?

I wound up writing my own version of norflash_writer.c that iteratively reads the disk and writes to the NOR Flash memory 16,384 bytes at a time until done, saving the boot signature from the first disk read and writing it to Flash at the end.

This appears to have successfully written to the Flash memory, but installing my own code as a boot image in Flash has left my C5515 ezDSP in a state where, even when running code downloaded from CCSv4 in a debugging session (which re-initializes the board according to usbstk5515.gel), interrupts handled by DSP/BIOS will not function!  I would certainly expect a decent emulator to override any existing machine state and provide the developer with a consistent starting condition from which to debug.  This does not appear to be the case.

I have since written a nor_read utility that parses the boot image in Flash memory according to the description on p. 6 of "Using the TMS320C5515/14/05/04 Bootloader" (SPRABD7), displays information about each memory section and writes the contents back to disk.  With this, I was able to read the boot image from an unaltered ezDSP and then restore it (with nor_writer) to the one I'd corrupted.

Some of this was complicated by the presence of the following in usbstk5515.h:

#define Uint32  unsigned long
#define Uint16  unsigned short
#define Uint8   unsigned char
#define Int32   int
#define Int16   short
#define Int8    char

Notice that using "Int32" in a program will give you a 16-bit variable!

Dan

HI Dan,

In the last day or so I've discovered the same buffer 'magic' you have. No check for size , error message and graceful exit. Anyway, I had trouble using the nor_writer sources in the debugger as well as a newly compiled version from said sources. The program would appear to come to ALL PASSED but would declare '0' bytes written and read. The only setup that worked was using the Precompiled OUT file from SPectrum and a small BIN. Their Demo is only 7.5K so that appeared to work. According to there sources, a 32K or < would work (as you pointed out) simply because the 2 buffers are contiguous.

 Real question is: Were you able to succesfully use Spectrums functions in the RevA sources they have online. I too, would rearrange it to do small blocks at a time. I don't want to start with functions that have hidden issues. Any help would be appreciated. Thanks.

Steve V

Hello Stephen,

I hope you can help me with the problem i have.

I am actually working wirh the C5515 EZDSP usb stick. My project is done, and what I want to do now is to load the code in the NOR memory that comes on the board trying to run the program without the CCS, so I read the documents about the bootloader, and downloaded the "Test Code" and "Demo" files from http://support.spectrumdigital.com/boards/usbstk5515_v2/reva/   (version 2).

I follow all the steps of the "readme_Programming_demo_image.txt" file,  included in the Demo and it apparently writes the data successfully in the NOR Flash memory, because it appears "ALL Tests Passed", but when I unplug and replug the board, all the leds are on, and they should blink following a sequence.

My problem is that I can not load the example program into the memory, and I have no idea why.

The steps of the demo are very easy and clear, but maybe I am missing something essential of anything else, like memory paramethers...I tried changing the .cmd file, the options inside it, with others projects. I have read many threads about configuring the projects, but the only thing that helps me is that I should initialize the PLL at the beginning of them.

And the .out file coming with the Demo works perfectly if it is loaded into the DSP using the emulator (connect target - load program - run).

This is the result of the execution of the nor_writer code that comes with the demo:

EXBUSSEL = 5000
01  Testing NOR Flash Writer...
Enter the file Name:
C:\Documents and Settings\Usuario\Mis documentos\ALVARO\PFC\USBSTK5515_demo\EZDSP_Sample.bin
Opening file...
Manufacture ID is: 1
Device ID is:     f9
     Erasing Flash 42 bytes
     Writing File: 42 bytes
     Reading and comparing File: 42 bytes
    PASS

***ALL Tests Passed***

The current version of the programs I am using are: CCS  v4.2.1.0004, and Code Generation Tools 4.3.8.

Thank you.

Regards,

Álvaro.

Steve,

Your question reaches me at a good time - I just returned to DSP development after a 2 month diversion, so it's a good time for me to review what I knew then and type it up for all of us.

As far as using Spectrum Rev A code, I have created a mashup that utilizes some Spectrum Digital C-language source code and some Spectrum Digital library calls (for off-chip audio codec initialization), combined with T.I. DSP/BIOS calls, Chip Select Library (CSL) calls and an off-the shelf audio encoder.  Don't ask me how I got all the include and library search paths set up; I just remember it was a charming process.

By the way, be careful:  one of my comments points out

// N.B. - This file causes conflicts if it precedes std.h

#include "usbstk5515.h"

where std.h is called by some chain of T.I. *.h files (from CSL or DSP/BIOS or other).  I think there are conflicts in definitions of types like Uint16, etc.

An important observation from my posting in another C5515 forum

          http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/69160/261049.aspx#261049

(which others have also pointed out):

Of all the sample code Spectrum Digital and T.I. provide with the C5515 ezDSP and in downloads usbstk1151_Demo_RevA.zip and usbstk5515_BSL_RevA.zip (and of all the examples in T.I.'s Chip Support Library in TMS320VC55XCSL-LOWPWR-2.01.00.00.zip), to the best of my knowledge only USB_Stick_Sample [project EZDSP_Sample] and C5515_eZdsp_Audio_Filter_Demo perform all requisite clock generator configuration and clock domain gating to run from Flash or EEPROM.  All the other examples assume that you have already booted into a program that has done this initialization before downloading the example code via the emulator.  The boot loader does what initialization it needs, but may not leave the system in the state your code requires.

There are other forum postings that discuss how to implement this initialization, partly by adapting pieces of the .gel code used by the Code Composer Studio debugger and partly by adapting other pieces of example code.  This may include, as needed:

·         Configure PLL dividers and multiplier for desired system clock frequency

·         Configure the real-time clock counter

·         Enable CPU clock domains via Idle Control Register (ICR) and the IDLE instruction [if you need to use the FFT accelerator or DMA memory controller]

·         Enable/disable peripheral clocks via PCGCR1 & PCGCR2

·         Reset on-chip peripherals via PRCR (timed according to PSRCR)

·         Clear interrupt flags

·         Enable/disable specific interrupts and reset the global interrupt enable [I then use DSP/BIOS to vector specific interrupts to their ISRs.]

·         Configure multi-purpose I/O pins

Be careful that you differentiate between registers mapped to memory space addresses and I/O space addresses in your code; some symbolic names are defined in various .h files. (There are also some directly-accessed CPU registers).

Another caveat:  Spectrum Digital uses different register names than T.I. and even T.I.’s own Chip Select Library cslr_sysctrl.h defines some different register names and conflicting register numbering than the DSP System User's Guide (SPRUFX5)!

Most initialization can be done in C language, but if you need to enable the clock domain for the FFT accelerator or DMA memory interface, you need to use assembly language to execute the IDLE command, but this can also be encapsulated in C compiler directives.  (Refer to some of the forum posts below.)  Some of EZDSP_Sample initialization code is contained in USB_Stick_Sample\asm\vector.asm, which entails an altered entry point in the project configuration, but this does not appear to be absolutely necessary.  There is an alternate assembly code initialization module called _c5515_init.asm, also mentioned in the posts below, that is meant to be called from main() instead of used as an entry point, but I haven’t tried it that way.

Another thing to note:  only the FFT accelerator and DMA memory port can be idled while the CPU is running [SPRUFX5: 1.5.3.1.2].  USB_Stick_Sample\asm\vector.asm tries to do otherwise and ends up enabling all CPU clock domains instead.

OK, since in reviewing all the forum posts I had bookmarked I made up an annotated directory for myself, here are some of its pertinent entries:

What exactly happens on "Connect", "Run" and "Halt" (in addition to the GEL commands)?

TI Home > TI E2E Community > Support Forums > ARM® & DSP Microprocessors > C5000 Ultra Low Power DSP > TMS320C5505 eZdsp USB Stick Development Tool > What exactly happens on "Connect", "Run" and "Halt" (in addition to the GEL commands)?

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/t/33709.aspx

ICR initialization required for clocking DMA – includes assembly code (derived from vectors.asm for an older processor(?)) posted by Raphael and C-embedded asm() directives posted by Jonathan Ibarra

NOTE:  In place of TMS320VC5505 DSP System User's Guide, SPRUFP0A, use TMS3320C5515 DSP System User's Guide (SPRUFX5); see note below

DMA not working when booting from SPI EEPROM, works when running from debugger

TI Home > TI E2E Community > Support Forums > ARM® & DSP Microprocessors > C5000 Ultra Low Power DSP > C5000 Ultra Low Power DSP Forum > DMA not working when booting from SPI EEPROM, works when running from debugger

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/70095.aspx

ICR initialization required for clocking DMA  – includes C-embedded asm() directives, posted by Richard von Lehe – ref: “user's guide for the DSP (sprufp0a) section 5.5, clock management”

 [NOTE: TMS320VC5505 DSP System User's Guide (SPRUFP0A)   “5.5.1.3     Clock Configuration Process” includes “5. Flush the CPU pipeline by executing 6 NOP instructions.”

  In          TMS3320C5515 DSP System User's Guide (SPRUFX5)       “1.5.3.1.3 Clock Configuration Process” no NOP’s are called for.]

Includes my posts re: delay required when initializing AIC codec (unrelated to DMA clocking)

Flashing in C5505 eZdsp

TI Home > TI E2E Community > Support Forums > ARM® & DSP Microprocessors > C5000 Ultra Low Power DSP > TMS320C5505 eZdsp USB Stick Development Tool > Flashing in C5505 eZdsp

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/110/t/11099.aspx

Rambling discussion about standalone initialization requirements, etc. and recovering from bad boot image in Flash

Includes C language PLL initialization code based on usbstk5505.gel  (p2) posted by Rijurekha Sen

James Huang refers to InitSystem() and ConfigPort() from eZDSP demo [USB_Stick_Sample\src\main.c] (p2)

 (links (p4) to: http://processors.wiki.ti.com/index.php/55x_FAQ#How_do_I_burn_my_code_into_the_NOR_flash_of_C5515_eZdsp.3F => http://processors.wiki.ti.com/index.php/Burning_NOR_flash_in_C5515_eZdsp)

CSL 2.10 Examples as standalone (flashed) applications

TI Home > TI E2E Community > Support Forums > ARM® & DSP Microprocessors > C5000 Ultra Low Power DSP > C5000 Ultra Low Power DSP Forum > CSL 2.10 Examples as standalone (flashed) applications

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/66178.aspx

http://code.google.com/p/c5505-ezdsp/C5515_eZdsp_Audio_Filter_Demo also contains initialization required for running from Flash.

Includes link to Real Time Power Monitoring code with c5515_init.asm [called from csl_i2c_power_monitor.c:main() ], posted by Christos Nikolaou (ref: http://code.google.com/p/c5505-ezdsp/)

C5515 CSL - Is the Idle Control (ICR) and Idle Status (ISTR) defined in LOWPOWER CSL

TI Home > TI E2E Community > Support Forums > ARM® & DSP Microprocessors > C5000 Ultra Low Power DSP > C5000 Ultra Low Power DSP Forum > C5515 CSL - Is the Idle Control (ICR) and Idle Status (ISTR) defined in LOWPOWER CSL

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/59334.aspx

Includes zip with c5515_init.asm, extracted from Real Time Power Monitoring, attached by T.I. employee Hyun Kim

I hope this helps you and anyone else avoid some of the pitfalls the rest of us have encountered.  I’ve been telling my co-workers that I really needed a 30 page starter guide to the most vital information and procedures, but T.I. has provided 30 links to 300 page documents, instead.  A simple initialization source library would also be nice, rather than “you can adapt it from … .”

Dan

Dear Dan, thanks for information provided on last post, unfortunately Texas does not seem too worried about it because so far made ​​no comment about your post. I am very disappointed.

About your post, one doubt still in my head, how flash codes bigger than 16Kbytes (0x4000)? How did you get it? My code has 75Kbytes, I made everything you suggested but this issue stills a mystery.

Please, could you help me?

Regards,

Andrea

Hi Andrea,

I wrote on 2010-10-22

I wound up writing my own version of norflash_writer.c that iteratively reads the disk and writes to the NOR Flash memory 16,384 bytes at a time until done, saving the boot signature from the first disk read and writing it to Flash at the end.

The version of norflash_writer.c provided by Spectrum Digital allocates buffers of 16,384 locations, which the fread( ) function fills with one byte per entry, and their code performs a single fread( ) of the entire file, so it is obvious their code was not designed to handle more than 16KBytes [although it may successfully transfer 32KBytes from the host PC's disk to Flash memory by overrunning from the tx[ ] buffer into the rx[ ] buffer].

Since there are only 256KB of SARAM and 64KB of DARAM in the C5515 DSP and 4MB of Flash memory on the C5515 ezDSP board, it is not always possible to transfer all data from the host PC's disk to on-chip RAM and then to the Flash memory in a single iteration.  What I did, therefore, was to stay with the 16KB buffer size, but instead of doing a single fread(  ) and corresponding burst of write operations to the Flash memory, I wrote a while loop that, for each iteration, reads up to 16KB from the host PC to the buffer in RAM and writes it to the Flash memory.  This loop repeats until the entire contents of the file has been transferred from disk to on-chip RAM to Flash memory.  During each iteration of the loop, I also read back the newly written data from Flash memory and compare it to the data buffered in the on-chip RAM.

To follow the example set by Spectrum Digital, my code does not write the first 2-byte word it receives from disk (containing the boot signature) to the Flash memory immediately, but sets it aside and only writes it to Flash memory once all data have been written.  In my case, this is after the loop I describe has completed.

The guts of my code consists of

    bytesRead = fread(bootSignature, 1, 2, hInputFile) ;
    bootSignature[0] = bootSignature[0] << 8 | bootSignature[1] ;
   
    pFlash = (Uint16 *)FLASH_BASE + 1 ;
   
    while ( bytesRead = fread(writeBuffer, 1, BUFFER_SIZE, hInputFile) )
    {
     ramPtr = writeBuffer ;
     for( j=0 ; j < bytesRead/2 ; j++ )
     {
      writeBuffer[j] = (*ramPtr << 8) + *(ramPtr + 1);
      ramPtr += 2;
     }
     
     norflash_write( (Uint32)writeBuffer, (Uint32)pFlash, (Uint32)bytesRead );
 

     norflash_read( (Uint32)pFlash, (Uint32)readbackBuffer, (Uint32)bytesRead );
     for ( j = 0 ; j < (bytesRead / 2) ; j ++ )
          if ( writeBuffer[j] != readbackBuffer[j] )
         {
             printf( "     Error at %dth word of this iteration \n", j );
             return 1;
         }
    
     pFlash += bytesRead / 2 ; // Address in words; length in bytes
     bytesProcessed += bytesRead ;
    

 } // END while ( bytesRead = fread(writeBuffer, 1, BUFFER_SIZE, hInputFile) )
 
 fclose (hInputFile);

    norflash_write( (Uint32)bootSignature , (Uint32)FLASH_BASE , (Uint32)2 );
   
    if ( bootSignature[0] != *( (Uint16 *)FLASH_BASE ) )
    {
        printf( "     Error writing boot signature\n\n" );
        return 1;

    }

It has been almost 6 months since I wrote my version.  That Spectrum Digital still has the same inadequate code posted on their web site is quite disappointing.

Dan

Hi Dan, thank you so much for your answer/code.

I did all you cited before (Feb/15) but when I try specify my entry point "reset_isr" an error occur (bellow link).

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/p/53200/370611.aspx#370611

Please, do you remember if it happened with you? Any idea?

Thanks again,

Andrea

Hi Dan,

I can not flash my code in C5515 eZDSP using 'nor_writer' code by digital spectrum. So I modified 'nor_writer' code by making use of your suggested code. But I flashing still does not work. Did you manage to flash using your code? If so then I must have made some mistake. Can you please help me on this.

Thanks

Abhishek

Abhishek,

I haven't worked on this code for some months, but I will add some information I omitted above - the type of the various variables I used.  There is a mix of byte and word addressing used by the C5515, which has a native word size of 16 bits.  I don't recall all the conventions as to when byte addresses are used and when word addresses are used, but here are my variable declarations for the code I posted above:

#define BUFFER_SIZE 0x4000  // 16,384

Uint16 bootSignature[2] ;  // 1 data byte  read from file  into each RAM word, then compacted
Uint16 writeBuffer[BUFFER_SIZE]; // 1 data byte  read from file  into each RAM word, then compacted
Uint16 readbackBuffer[BUFFER_SIZE/2]; // 2 data bytes read from flash into each RAM word

    Uint16 j = 0;   // Destination word index to use during byte packing
    Uint16 id[3] ;   // Numeric manufacturer & device ID codes
    Uint16 *ramPtr;  // Source word pointer to use during byte packing
    Uint16 *pFlash ;  // Pointer to starting word location in Flash memory to write
    long fileSize = 0 ;
    long bytesRead = 0 ;  // Count of bytes read from input file
    long bytesProcessed = 0 ;
    FILE *hInputFile;

Hope this helps some,

Dan

4431.nor_writer.zip

Hi Dan,

Thanks for all the help. I could load 76 KB bin and run it in stand alone mode on c5515 stick. I have attached my whole project folder, so that others save some time in making changes to the program.

Thanks again,

Rijurekha

I could load large bin files on the c5515 ezdsp stick and run in stand alone mode.

But I cannot do this for the program CSL_MMCSD_SdCardFSExample. This project is created as bios project and has a VC5505_CSL_BIOS_cfg.tcf file unlike other projects which has VC5505.cmd.

Other than the normal PLL configuration to 100 MHz in the beginning of main function of the program which I want to run stand alone, is there any other change needed to be made?

Can someone please help?

Thanks,

Riju

Riju,

I have been away from DSP development for a few months now, but I did succeed in getting a DSP/BIOS-based program to boot from Flash and run.  You may need to do some clock gating.  I posted a lot of general considerations about the topic earlier in this thread, along with links to other pertinent threads, on 02-15-2011.  As I said then, T.I. really needs to provide a concise starter guide to initializing and booting this chip and to using DSP/BIOS and the Chip Support Library.  The information provided is too dispersed and incomplete.

[Some of my links with the "#" symbol in them fail if you click on them.  You have to copy the link manually to the address bar in your browser and replace "%23" with "#"]

Dan