MODIFYING/placing new boot code for C5510- ON CFLASH (EMIF)

You have several questions and topics here, so I will try to break them down:

1) Register Configuration: Adding this is simple when you use the hex55 utility command line options. There are some limits on which McBSP registers you can change, particularly clock-related registers. However you should be able to quickly find out what works and what does not by altering your bootloader image.

2) Loading "my code" as well as original boot code: How do you want to load your code? Do you want to use the bootloader or the JTAG interface? What is the purpose of leaving the original boot code undisturbed if you're not going to execute it? How do you expect that the DSP will ever have access to the original boot code?

2a) If you want to use the bootloader to load your code and the original boot code, then you'll need to combine both images into a single boot table. The original boot code will no longer be accessible if you change the execution entry point unless your code is aware of the old entry point and manually jumps to it. There are no tools to combine multiple, independent code images into a single bootloader image. You would have to manually link your program so that none of the code segments or initialized data segments overlap, and this might not be easy if both programs will not fit into memory at the same time. If you have the source to the original boot code, then your easiest solution, by far, is to extend the original source code to include your own code additions and create a bootloader image from your expanded sources using the normal procedures.

2b) If you want to use a JTAG interface to load your code, then you do not really need to do anything special to avoid disturbing the original boot code. The DSP has no Flash memory, so the original boot code is loaded every time the processor is reset, assuming that the GPIO pins select the CF source. You are free to overwrite the original boot code in RAM without affecting the bootloader image in CF, but sometimes you may have trouble with the original boot code launching before you can stop it with the JTAG debugger.

All things considered, you're probably better off just making sure that you have an adequate backup of the original boot code and then just overwrite it until you've finished your development process.

3) There are many concepts to learn as a beginner, so it might be very useful to start with the DSK first, assuming that you already have access to one (my company's budget was such that I received the DSK after my custom hardware was up and running, and yet I still learned a few things on the DSK).  After you are familiar with most of the concepts, then you can move on to your custom hardware with fewer unknowns.

4) There is no point in including all RTS/CSL/BSL in the boot program because whenever you port a new application (ASM/C) to the DSP you will link in the needed library functions at that time. The bootloader is not a dynamic linker like a general purpose operating system loader. You must create a self-contained image for one firmware program that includes all library functions and build that into a single boot table.  There is no mechanism for combining code from multiple sources during the boot process.  Each new port that you finish will completely replace any previous bootloader image, and thus there's no point in having the RTS/CSL/BSL image maintained separately.  This will probably all become more clear once you use the Code Composer Studio linker tools and go through the process of creating a bootloader image with hex55.exe

Overall, some of the things you're describing are either never done in practice (at least not for embedded systems), or are fairly advanced topics for a beginner. You also seem to be focused on specific technical details of a solution because you assume that they're the correct steps to take to reach your goals. However, it would be better to clarify your actual end goals before focusing too deeply on specific technical details, so that you are free to use the correct solutions instead of heading down the wrong path.

My apologies if I've misunderstood your goals here. Perhaps what you really want to do is easier than I think, if only we can clarify what you want to end up with.

Further questions:

A) What sort of information do you intend to pass along McBSP2 on the common link between the MSP430 and the 4 C5510 chips?

Answers (to the best of my knowledge and experience):

1) There is no need to configure the McBSP2 via bootloader register commands. Instead, the bootloader will execute your code which should be designed to start by configuring the McBSP2 peripheral. There are actually quite a number of settings that must be carried out by the firmware at startup, and these are handled in your firmware source. The only time the bootloader needs to alter registers is when those registers affect the loading of the boot table itself. In your case, the bootloader cannot load firmware over McBSP2 because the bootloader is limited to loading the boot table over McBSP0, thus you should not need any register initialization commands.

As for documentation, you need to visit the C5510 chip page and download all of the appropriate documents. Once you've read those documents, follow all links within their content to other documents. I have about 36 separate documents concerning my C5506 chip, so I imagine that you might have a lot of reading ahead of you.

2) It appears that you have some sort of original boot code on Compact Flash.  My understanding is that Compact Flash is a removable medium.  If you would like to preserve the original boot code, then I suggest that you simply unplug the CF card and set it aside.  Buy a new CF card for experimentation with your new firmware.  That should be all that is necessary to give you a fallback.  Anything beyond this is most certainly too complicated for a beginner.

3) Your DSK should come with documentation and sample firmware source code. Apart from that it should be identical to any other C5510 board except for the external peripherals.  The advantage of the DSK is that you basically do not have to doubt the hardware.  If something doesn't work, then you can almost certainly blame it on firmware. Meanwhile, if you use your custom hardware then when something doesn't work you have no way of knowing whether it is a hardware problem or a firmware problem (unless, of course, the custom hardware has been thoroughly tested and proven).

4) It seems apparent that you should start using Code Composer Studio along with your JTAG interface. You will be able to do quite a bit of firmware development and testing without every bothering with a bootloader. It's only after you have things working well and feel confident that you might want to create a bootloader image to save on CF for operation without CCS. When you reach that stage, you should read the appropriate documents that are found as part of the set of files concerning the C5510.

The DSP ROM is fixed. You cannot add your code to it. However, the bootloader effectively provides the same thing if you just let it do its job of loading your code into memory.

Handing control over from bootloader to your code is automatic. As you are already aware, there is an entry point in the boot table.  This is the starting address of your code.  The bootloader will always jump immediately to your code - there is no option to leave out the entry point.  From this point on, you effectively have the same performance as if your code were in ROM, in that it will all be available.  The only difference is that your code is not truly Read Only since it is loaded into RAM, so make sure you don't have any memory-trashing bugs in your code or it might overwrite itself.

One thing I have been assuming all along is that the C5510 can be configured to access the bootloader on CF. I assume this is how your DSK works, how your custom hardware works, and how your final solution will work. However, the bootloader can be configured to read from a variety of locations. The thing to keep in mind is that the bootloader operation is a one-time process - the DSP is reset, it jumps to the bootloader, finds the appropriate device from which to read the boot table, then commences reading the entire boot table from the memory device and interpreting the commands.

You mention that your "codes can reside on the flash from where they can be accessed and run by the DSP."  It seems that you imply that this will be interactive or perhaps that more than one program can be accessed.  However, this is generally not true unless your firmware is way more complex.  In general, embedded systems load all of the code that will ever be needed for operations and then that's it.  Once the bootloader process reads one set of code from CF, it will copy it to DSP memory and then jump to the entry point. After that, if you somehow need more code then you have to create a system that is a lot more complex because you have to duplicate the process of the bootloader separately.  I recommend that you fit all of your needed code into a single image, place that in the bootloader, and then not try to load any further code from CF.  This will be far simpler than dynamic loading of various and assorted pieces of code.  Keep in mind that the DSP is not a general purpose computer with an operating system running multiple programs loaded from disk.  Instead, the typical scenario is an embedded and dedicated program which is loaded exactly once and which then responds to all possible inputs correctly.

Your next message mentions external memory on EMIF and the need to pre-configure this.  Again, there is no need to pre-configure the EMIF in the bootloader unless the bootloader is reading from EMIF (in which case the configuration is restricted by the bootloader ROM).  Like before, your code will start by configuring all hardware via the CSL, including the EMIF, and this should all happen before you enable interrupts.  By the time you enable interrupts on the DSP, all pre-configured requirements should have already been handled by your code's initialization routines.