Flash hex utility issues for C6713

Aditi,

The app note examples use memwidth and romwidth both equal to 8.  You say that you have generated a binary file using these settings, but have you actually tried to boot to it?  I'm curious to know whether or not it worked correctly.

Joe,

It did not work.

Can you suggest any debug methods of how to go about it?

Also if we use -memwidth and -romwidth =8, is it supposed to boot correctly?

Thanks,

Aditi.

Joe,

Can you also please look at the following post of mine

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/127494/456213.aspx#456213

and suggest a solution. I really need this very urgent.

Thanks,

Aditi.

Joe,

I am attaching the screenshots of the memoryview (of the Flash) and

the disassembly view after booting from Flash, connecting the target and Loading symbols.

The opcodes do not look right. If you look at clearly all of them have 0xFFFFFFxx where xx is the

actual value at each byte location in Flash mem view.

Something does not look right in creating the hex files.

Can somebody please point that out and help ASAP.

Thanks,

Aditi.

Aditi,

From your description and screenshots, it sounds like the problem is a disagreement between the binary file format (as generated by hex6x) and your flash-writing code.  Could you post the binary file generated by hex6x?  Maybe your flash utility is treating each byte as a 32-bit word.

Joe,

Please find attached the .hex file generated by the hex6x utility.

This is the following command I used at the command line

hex6x.exe -memwidth=8 -romwidth=8 -i -map=map -o=dskflash.hex dsk6713_custom.out

Let me know if this is right?

Also here is the map file created by the hex utility

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

   CONTENTS: 00019554..00019753   dsk6713_custom.out(.trace)
             000197b4..000197f3   dsk6713_custom.out(.sts)
             00019e00..00019e58   dsk6713_custom.out(.printf)
             00019eb4..00019ecb   dsk6713_custom.out(.log)
             00019f10..00019f17   dsk6713_custom.out(.data)
             00019f18..00019f1b   dsk6713_custom.out(.args)
             90000000..9000015f   dsk6713_custom.out(.boot_load)
             90000400..9000407f   dsk6713_custom.out(.text)
             90004080..90007c5f   dsk6713_custom.out(.bios)
             90007c60..90008dab   dsk6713_custom.out(.cinit)
             90008dac..90008db7   dsk6713_custom.out(.trcdata)
             90008dc0..900092df   dsk6713_custom.out(.sysinit)
             900092e0..9000931f   dsk6713_custom.out(.gblinit)
             90009400..900095ff   dsk6713_custom.out(.hwi_vec)
             90009600..9000972c   dsk6713_custom.out(.const)

4370.dskflash.zip

Thanks,

Aditi.

Hi,

Can you please reply. I need the Flash boot to work and I need

your help in debugging.

Thanks,

Aditi

Hi ,

I have found the problem. My problem is similar to the one in the following post

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/90781/316955.aspx#316955

Except that the padding is 0xFFFFFF to all the bytes. I am not able to understand how to solve it.

When I use the custom Flash burn code to write to the Flash, I can see the hex file being written to each byte location.

Once I power-cycle the board, and try to debug the Flash-boot by just conencting (without the GEL file) and

initiating PC to address 0, the opcodes are as seen in the pictures attached above. And the mem view of Flash looks different

as follows. I cannot understand this behaviour. 

Can somebody please point out what could be the reason for this behaviour. I really appreciate any help.

Thanks,

Aditi.

Aditi,

What peripheral are you using to access the flash memory?  Is this a normal EMIF operation, or is it a SPI flash, etc?

I still think that the issue is a discrepancy between the software you're using to write to flash and the software you're using to read from flash.  There are two possibilities:

1. The flash writer is padding each byte with 0xFFs to reach 32-bit width
2. The flash reader configuration is incorrect, and it is falsely padding each byte with 0xFFs to 32-bit width

I would check to see if there is some inconsistency (i.e. one program expects to operate on Int8 array, while the other expects Int32) that could explain this.  (Also, connecting without the GEL file could mean that you're missing some peripheral/EMIF configuration that is required to correctly read flash memory.)

Joe,

I am using the EMIF interface to write to the Flash.

And the thing I observed was because I don't use the GEL file after burning the Flash,

the default setting of the EMIF CE1CTL register after reset is configured for 32-bit async

memory. Could this be the problem?

Also, how can I change the EMIF configuration before the DSP reads from Flash.

I have the code to initialize the PLL and EMIF in the secondary bootloader code

but the DSP might be reading the Flash even before it configures the regs.

Can you please suggest what can be done?

This could solve my problem.

Thanks,

Aditi.

Hi Aditi,

Have you able to resolve your query?

Best Regards,

Ankit Agrawal