Memory Protection for L1 CACHE

The DM6446 DSP core does not support the standard memory protection you find on the C64x+ mega module, and even if it did I doubt that memory protection would cause a problem like this, the protection in devices that support it just fires an exception upon a bad access as opposed to physically preventing such accesses.

It sounds kind of strange to stop execution of one program and than load another to do cache configurations, perhaps something is getting messed up with this transition? I do not now of any particular normal conditions that would prevent writes from going through to the cache registers...

I guess its an anomaly, if I allow the program to be executed and then load a new program then it works fine. But if I halt a program execution in between and try to configure, its not allowing me to do so, I have to restart the board to make the Cache register configurable.

Regards

amit

Is the first program you run in a bad state when you stop it to load the second, or is it still working properly, and does the first one have any particularly odd cache operations it has to do? This is fairly unusual, as the cache configuration registers should not get locked up like this, another thought is you may want to double check the register values from the view memory window to see if they actually are changing and this is not just a problem with CCS viewing the register.

I don't know exactly what bad state would be considered as. Although, there are no cache related operations performed before  I halted this program. As you said, I had checked the CFG Registers using memory view, thats how I came across this problem. When I ran the second program in debug mode, I found that both L1P and L1D are set to maximum configuration (32K in this case), and if I try to change it using a pointer dereferencing, there is  no change in the corresponding CFG memory locations. But, If i make similar changes for L2 the changes are reflected in the memory location (L2CFG) too. I would test if this thing happens, by halting a random C program and loading a new program.

Try doing Debug -> Reset in CCS before loading your second program.  Although you've loaded new code, you might actually still be executing the old code due to cache coherence issues. 

Actually, I would like to add further to the mentioned problem. I tried changing the register configuration after the board restart, using a new program, its not updating at all. I want to fix my both L1's to 16KB, but this doesn't seem to work. I have to manually change the register contents using View -> Memory. I will try using DSP/BIOS and BCACHE API's, to see whether I can change the map.

I used the DSP/BIOS and using BCACHE_setSize(), I was able to configure the L1 Cache. Still,  some type of lock is engaged, if I try to change the config using memory address of the register. I don't understand why this is occuring, because for couple of months I was able to change the cache config manually?

Did you try resetting the board before loading the code?

Brad is probably right, stoping execution of one program and loading another in the middle without resetting the target is likely going to cause strange issues, it may work sometimes but you could end up with the device in a odd state. As he mentioned previously you could still have part of your old program code and data in the cache still when you load the new program, so when the new program starts executing you could end up running portions of your old code mixed in with your new code which will very likely throw the CPU off into the weeds and could end up putting the device in a state where it does not work right, and things like not being able to access the cache configuration registers may happen. I cannot say for certain this is exactly why you are seeing what you are seeing, but it is one reason you should avoid doing what you are doing.

Yes you both are right, but the board is in such a state currently that, I am not able to configure the cache directly. I had done reset and also restarted the board, but it is not allowing me a direct access to the register. As mentioned in my previous post, I m able to change the configuration using BCACHE though.