On-Chip Boot Loader - Delay between "launch" and ... everything else is?

Timothy,

You will need to make some clear references in the documentation to what you are asking about. None of this rings a bell in my recollection.

The C6748 starts running the bootloader ROM / RBL after being released from reset. The RESETOUTz signal will be released to go high after the hardware reset sequences have completed, and that delay from RESETz / to RESETOUTz / is specified in the datasheet.

The RBL detects which boot mode is selected and will initialize any components required for that boot mode. If the PLL has to be initialized or changed for your boot mode, the standard PLL initialization time is also specified in the datasheet.

When the HPI master has completed its downloading to the C6748, it will release the DSP. There will be a matter of instructions before the DSP jumps to the indicated starting address which corresponds to launching the application.

I know of no reference precisely defining these delays, and I know of no customer who has had concerns over these delays, so your references to "what I can tell" will help us figure out how to help you.

Your quotation from the Bootloader document is a mis-quotation. It should be "The bootloader configures all of DSP L1P and L1D RAM as cache." This does match the power-on values, but that is not "allowing 1/2 of L1D to remain 'as RAM'". The document is correct. Your quotation is wrong and your statement of the default power-on setting of the cache is wrong. We may need to dig deeper into where you have found these incorrect statements or to determine if our documents are confusing in some way. I do not see the bootloader document being confusing in this case.

Regards,
RandyP

It's me again. The boot loader leaves L1P as "all cache" and configures L1D as "half RAM half cache". This can be verified by attaching a microprocessor emulator to the C6748 via JTAG, and halting the processor at the reset vector, and then after the boot loader is allowed to run. The boot loader uses the RAM half of L1D for some purpose, as can be verified by observing it updating memory values in that region while performing its duties.

When the boot loader exits using the process detailed in the data sheet (i.e. for HPI bus mode, the bit exchange protocol), it does reset the cache memories to the C6748 default value as shown in the C6748 data sheet. Thus, L1P and L1D are set to "all cache" upon exit from the boot loader.

Interrupting the boot loader by using a processor emulator and changing the program counter to the software start address, for example, as is normally done in CCS (any version), bypasses the boot loader exit protocol and leaves the cache set as L1P all cache, and L1D as half-cache, half-RAM. This can also be verified by either starting a debug session with CCS, or by using an emulator and changing the program counter value to the application start address (and thus bypassing the boot loader exit protocol).

The delays I'm referring to affect host loading operations via HPI. For FLASH, etc loading, they are not an issue, because the boot loader is fully in control of the loading operation. For HPI loading, however, the host has no specified delay values from DSP reset to "boot loader ready", nor from "launch application" to "boot loader exit has occurred". TI has not supplied these values; thus, the programming of an HPI loading operation must either guess at the maximum current or future delays. It's very difficult to measure them accurately, as no discrete outputs are available to do so. I suppose a person could measure the exit delay by tracing through the boot loader instruction stream, and there may be some way of measuring the reset release to HPI register indication that boot loader is ready. However, that still leaves these delays unspecified; and thus when TI updates or modifies the boot loader the downstream application has no guarantees that these delays have grown past an important value.

The statement from the SPRAAT document that the boot loader uses L1D and L1P is fine, I have no issue with that, nor that the application should not load program data or constants there. But, the data sheet is incorrect in its assertion that the boot loader uses L1D as "all cache", at least for the HPI boot mode. Only after exiting via the normal boot exit protocol is L1D set back to "all cache".

Why Code Composer doesn't activate a boot loader "normal exit" protocol I don't know; but, it doesn't. Thus, upon entry to the emulation debug of Code Composer, the processor is not set to its values as specified in the boot loader documentation. Rather, it is set to what the boot loader has set them to.

Although I understand this now, it is very confusing when looking over processor register values, etc, as they are most assuredly not set as expected. Now that I know how it works, etc, a trade secret, I suppose. It also imposes additional software initialization requirements on the emulator compatible software, which must re-establish power-on values of certain registers, etc, because Code Composer does not follow the boot loader exit protocol but rather interrupts the processor and sets the program counter and bypasses the boot loader exit protocol.

So, my suggestion here is somehow to indicate to developers these details. I spent a lot of time here puzzling through why the register settings in Code Composer do not match the C6748 chip defaults, and also working around it by installing software to set them to what should have been the power on defaults. I'm not sure how to do that, and hopefully this all makes some sense to you.

Timothy,

Timothy Frank said:

The boot loader ... configures L1D as "half RAM half cache". ... The boot loader uses the RAM half of L1D for some purpose, as can be verified by observing it updating memory values in that region while performing its duties.

Observing that the L1D RAM space has activity is not sufficient to determine the Cache/RAM allocation. When you stop the processor to observe the activity (or watch it in real-time), please observe the value of the memory-mapped register L1DCFG to see if its value is 3 or less. This register will tell you the state of the L1D Configuration. I am not saying that your statement of L1D cache = 16KB is incorrect, I am saying your observation does not lead to that conclusion since you will see activity there when used as any combination of SRAM/cache.

Timothy Frank said:

Interrupting the boot loader by

I am sorry, but I do not completely follow your idea here. If you abort any process, including the bootload process, and the processor is in some state that is not compatible with your application, then the processor must be set to the proper state. This can be done using CCS GEL scripts that set the cache mode to whatever you want. I often configure CCS GEL scripts to automatically set cache the way I want it whenever I load a program. I think many of our default GEL scripts do this.

Timothy Frank said:

The delays I'm referring to affect host loading operations via HPI.

Have you observed a failure when your host processor starts sending commands at any time after RESETOUTz has been observed to go high? I do not recall anyone having a problem with this, but of course I would not have heard from everyone. If you assume the spec is 0ns after RESETOUTz = 1, do you have any problems with your HPI loading process?

Timothy Frank said:

The statement from the SPRAAT[2] document that the boot loader uses L1D and L1P is fine,...
But, the data sheet is incorrect in its assertion that the boot loader uses L1D as "all cache", at least for the HPI boot mode.

I did not find a reference in the datasheet SPRS590f to the bootloader's use of cache. I have already addressed your mis-quotation of the SPRAAT2f Application Note, so please refer to my previous reply and tell me which part of my statement you disagree with. We can get this cleared up if we are both quoting the same thing and reading the same thing.

If you want to load your application using CCS and debug it that way, you need to select the Emulation Debug mode. That is why this mode is there and it is documented in the Bootloader Application Note. If you want to abort any operation, including a bootloader process-underway, you will have to deal with the proper initialization of the device. You know exactly what you are doing and what you want the outcome to be.

CCS only knows what you tell it. CCS does not monitor your emulation activity to make decisions about what you would want done under various conditions. That could be devastating when you are trying to debug difficult issues.

If you will check the value in L1DCFG, we can reach agreement on the state of the L1D cache/RAM setting. I do not know that any other agreements will be coming, but we can certainly try. Your requirements are important to me and to TI, and we can come to agreements easily when we are looking at this similarly.

Regards,
RandyP