Compiler/TDA2: Incorrect memory accesses after enabling and disabling MMU

Hello,

We have software that runs on an A15 core and does work based on a message sent through the mailbox queues from the other A15 core in the TDA2xx. We are using the mmu_a15_data_validation_app_main example in starterware_01_05... as a reference. The software does not use interrupts and is all Polling-based. We're using MMU and cache to speed up some functions but not all. By enabling and disabling MMU like in the provided starterware MMU example we occasionally see odd behavior when running software on subsequent commands.  

The below is an example of our software flow.

uint32 message;

main()

{

//1.  MMU config and init same as example

while(1)

{

//2. wait for command through mailbox

wait_for_new_message();

//3. print and parse message from mailbox

UARTprintf(" message:%d \n", message);

if(message == 1)

{

UARTprintf(" Branch 1 \n");

/// 5. do something, no MMU

}

if(message == 2)

{

UARTprintf(" Branch 2 \n");

/// 6. do something, no MMU

}

else if(message == 4)

{

UARTprintf(" Branch 4 \n");

/// 4. enable/disable MMU around functions

MMUA15Enable(&gMmuTable);

function();

MMUA15Disable();

}

}

}

In the above example we print the message prior to the IF checks and we confirm that it's as expected. The IF checks however, and subsequently the branch that is entered, does not match because we end up seeing a different Branch print statement. 

We've narrowed down the cause of the behavior to Enabling and Disabling MMU. If we never enable/disable mmu then we don't see an issue. Enabling and disabling MMU even just once can cause the above odd results but it doesn't always happen. Essentially we change software, compile and if we see an issue then the issue is repeatable on each system reboot and shows up in the same exact way. If we change software, compile, and don't see an issue after running each Branch including ones with MMU enabled/disabled then we don't ever get the weird behavior. Adding more print statements or any other inconsequential software can cause the odd behavior to change, like entering a different wrong Branch than before, or make the issue go away completely. So there also seems to be a relation to the compiling.

 

We've seen this happen with multiple variables including pointers and not just the top level message variable. Within each top level Branch can be additional sub-branches that are based on other variables. These sub-branches have also shown the similar odd behavior where we print a variable and it looks correct but then the IF-checks result in the wrong branch. When it's a pointer that is affected we'll usually get a core halt since it's now accessing wrong memory. For some of the pointers that have had issues we only load them once at bootup and somehow they get modified after enabling/disabling MMU in a Branch that doesn't even access those specific pointers. By printing the pointer value before accessing it we confirmed that these bootup-loaded pointers are being changed. These are pointers that are properly loaded and working correctly for multiple loops before we run a branch with MMU. 

Debugging this has been difficult since any change in code can change the behavior. However we have been able to rule out that our software is doing any of this and any issue seems to only come up after running a branch that enables/disables MMU. We are using the mmu_a15_data_validation_app_main example in starterware_01_05... as a reference and we're calling the same exact functions and it is being configured and initialized the same way. Our compile environment uses the default make rules that come with the starterware folder. 

What are the potential reasons why enabling and disabling MMU would cause the above results? 

Why would modifying the software and recompiling it change the behavior when what is modified are only print statements?

Thank you.