Genady,
You are making this very complicated and may be leaving out very important details. From what you have said, it is definitely a complicated and dangerous way to try to implement your bootloader. Let me quote a few statements that worry me:
[quote user="Genady Kagan"]
But in secondary boot loader , usually the L2 cache is disabled
I have L2 already enabled
[/quote]
This is a red flag #1. If the usual process is different from what you are doing, then you should go back to the usual process. Try leaving L2 cache disabled until you get to the final program and let it take care of enabling cache as it needs to. Do not make your bootloading job harder than it needs to be. by doing things differently.
[quote user="Genady Kagan"]
When I set the breakpoint on “ B .s2 B2” command , I see that I jump to the right place and see the right code (in disassembly window)
But when I try to execute this ,step by step , something strange happens .. its seems , like I see one code and execute another
Seems to me like the problem with L1P coherence .
[/quote]
This sounds like a classic example of cache problems. Using the CCSv5 Memory Browser, you can look at the program memory where “ B .s2 B2” is located and confirm that caching status of that location. The Memory Browser uses color coding to show if that location is cached or not. You can select on or off all three of the caches to see what is in the physical memory location (all unchecked) and compare that with what is in the cache, if anything, by checking the three cache boxes one at a time.
[quote user="Genady Kagan"]
I am trying to implement the tertiary boot loader (the first boot loader , its copying of 1k from flash, the secondary , its 1k that copies the code of tertiary boot loader to the memory,
And the tertiary boot loader, copies the final program to memory and jump to c_init of main program)
[/quote]
Which one initializes the EMIF for external memory?
Where do the secondary bootloader, tertiary bootloader, and final program run from in memory? Where are the tertiary bootloader and the final program loaded into memory, if different from their run location?
[quote user="Genady Kagan"]
The tertiary loader and final program share the same memory space , except the function that makes copy of code , and variables , that I use in function
Both , code function and variables place in separated memory segment
[/quote]
Sharing the same memory space just begs to have a problem. You should consider this to be the wrong way to do this. Load or certainly run the tertiary bootloader from some memory space that is either not used at all by the final program, or is uninitialized data space such as heap (.sysmem) or stack or other large uninitialized data space.
When the tertiary bootloader copies the final program onto the same memory space where the tertiary bootloader is running, almost everything that can happen is bad. Please, stop doing it that way. Or at the very least, stop doing it that way, get it working, then go back to doing the difficult way when you have spare time in the project.
[quote user="Genady Kagan"]
asm(" ldw *B1, B2 ");
//cache operations (or anything)
//branch to c_init of new code
asm(" b .S2 B2 ");
[/quote]
You cannot interleave assembly and C like this. Yes, you can write it and compile it like this, but you cannot expect register values to survive from the "ldw B2" all the way down to the "b B2". This is why I asked you about setting a breakpoint on the branch instruction and see if it goes to the right place. More specifically, you should inspect the B2 register from the Register window to see if it has the value of _c_init of the final program. And continue to use the Memory Browser to inspect memory through the cache color codes.
Since you have not mentioned where the tertiary bootloader is being loaded from, or where the final program is being loaded from (Flash, Ethernet, serial port, etc.), it is not possible for me to fully understand the system operation of the bootloading.
Other than the complexity of the source of the programs, the job of the bootloader should be as simple as
1. Invalidate all cache.
2. Load the program and initialized data, but not on top of the bootloader's program and data.
3. WritebackInvalidate all data cache and invalidate all L1P.
You were originally having trouble with the L1P/L1D global commands, but even if those were solved you would still have problems with the whole process because of the way the rest of the code and process are being done. I do not know if what I have said is helpful, but I hope it is not offensive in my choice of words. I need to tell you my true opinions or my advice is worth nothing to you, and that may be the case anyway. Best of luck.
Regards,
RandyP