Placing constants at specified memory addresses for burning into external flash

Hi Brad,

Can you tell us more about your system? Is this a parallel 16-bit Flash memory or serial?

Where is your firmware loaded from?  Will your firmware be loaded from this same Flash or some other source?

What is the requirement for the AAAA5555 constants?  Is some other device besides the DSP reading these specific memory locations? ... or is your DSP firmware the only reader?

I'm not sure whether I'll end up having an answer for you, but if I get a clearer picture of why you're doing what you're trying to do, I might be able to offer a suggestion.

Hi Brian,

Sure, I can give you more details about the system.

Our 5510A DSP is connected to a parallel 16-bit Flash through CE1n  which is the where the firmware and two (2) 16-bit constants (0xAAAA and 0x5555) is stored.

These constants are only read by the DSP running the firmware.  No other devices need to access these constants.

Since my posting I have attempted to use the DATA_SECTION pragma to store these two constants into two dedicated memory SECTIONS that are one word (16-bits) each.  However, I wanted the compiler/linker and hex55 hex conversion tool to create one or two simple S-records that store the 0x5555 and 0xAAAA constants in the CE1n word locations 0x20FFFE and 0x20FFFF, respectively.

Any help you could provide would be appreciated.  Thanks in advance for your willingness to help.

- Brad.

Thanks for the additional information.  I believe you are on the right track by using SECTIONS to place your constants at a specific memory address, and the DATA_SECTION pragma to associate your source code with these specific addresses.  All that remains is to determine to correct command options for hex55.exe

Are you using Boot Mode 1011 or 1000?  The former uses the bootloader to read a boot table from Flash, while the latter skips the bootloader and executes the Flash directly.  I don't believe that the former mode will work for you, since you can't write to Flash this way; thus, I assume you're using the latter boot mode.  See SPRA375F for details.

I am using a serial 8-bit Flash to host a boot table so that my code is loaded into RAM for faster execution, so my experience is with the bootloader format.  The options I'm using for hex55 include "-boot" which condenses all of the code and data into one contiguous region in the beginning of the serial Flash memory space, but with address and length headers so that the bootloader can expand these sections throughout the memory map that I have created with SECTIONS.  In other words, the bootloader copies from contiguous Flash memory to RAM, then executes from RAM.

I believe that all you need to do is run hex55 with a command line or command file which does NOT include the "-boot" option. Then your sections should be placed exactly where your want them in the output .hex file.  The caveat that I would like to point out is that execution is slower directly from Flash, which is why many firmware images are copied from Flash to RAM before execution.  The fastest 16-bit parallel Flash that I am aware of has a 35 ns access time - 7 times slower than the 5 ns instruction cycle of the C5510.

I am not aware of any method to combine the two options at the same time.  In other words, I don't think you can have a boot table (which allows faster execution at run time) and also place SECTIONS at specific offsets in the Flash.  However, you could manually edit the .hex file, or perhaps if you read more about hex55.exe you can discover more features than I've used.

Note that if your goal is merely to use 0x5555 and 0xAAAA as an indicator to confirm that the Flash is not empty or invalid, you could potentially just use the bootloader itself as such a verification.  An empty Flash won't give the bootloader anything to run.  Assuming that your firmware fits in the 5510 RAM, you could just use the Flash as a bootloader.  I'm also assuming that execution from RAM will be faster than from Flash.  In other words, I'm still a little hazy as to what advantage you're gaining from placing those constants into your Flash.  If the above does not answer your question, then perhaps you can explain in further detail what you hope to gain by having 5555 and AAAA appear in the memory image.

Sorry for trying to second-guess you.  Hopefully the above gives you some clues as to the options available.

Hi Brian,

Thank you for your prompt and detailed reply.

I probably should have provide more details on how I'm using the firmware that is loaded into the flash.  I'm using the external 16-bit EMIF boot mode (1011) so I'm using the bootloader to read the boot table from flash so the firmware is copied from the flash and executed from RAM.

I have already tested what I want to accomplish by manually creating an S-record that stores the 0x5555 and 0xAAAA constants into the appropriate flash locations and then use a text editor to manually append the S-record .hex file that contains the boot table that was created by the hex55 utility.  However, I was hoping that I could utilize the C55x compiler/linker and/or hex55 utility to store these constants at the correct locations for me.  So far I haven't seen a way to use the hex55 utility to convert a COFF-based .out file to a .hex file that contains the boot table(s) and combine that output with another file that contains S-records.  I have considered writing a small utility that will combine the .hex file produced by the hex55 utility with my manually created S-record file that contains the constants.  That might be my best option if I cannot use hex55 to create a .hex output file both with, and without, the -boot option.

Also, I'm using the constants to verify that the firmware has been completely loaded into the flash to determine if the firmware can be loaded, and executed, out of the DSP' RAM or if it needs to be reloaded.

I appreciate your response and any other comments/ideas you might have would be appreciated.

- Brad.

I assume that you have already found a solution and moved on. If so, it might be helpful to the E2E community for you to document your solution here.

In case it is helpful, I will mention what I have done. I use serial Flash for the bootloader. I have written a program that can write my bootloader image to serial Flash or read my master image and compare it to the contents of the serial Flash. This basically solves the problem you are attempting to solve by placing a pattern, 0x5555 0xAAAA, except that my solution is more robust because it compares every byte, and does not just check two words. In fact, since my program can both write and verify, I have arranged the code so that it always performs a verify before a write. This has the minor advantage of saving my Flash from excessive erase cycles in the event that I accidentally try to write the same information twice in a row.

I assume that my solution would work equally well for parallel Flash, although the low level erase, write, verify commands would obviously be different.