We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi there,
Iam using LPC2368 controller and Keil uVision3 IDE with the GNU compiler. My Stack settings are as follows,
.equ Top_Stack, 0x40004000 .equ UND_Stack_Size, 0x00000008 .equ SVC_Stack_Size, 0x00000008 .equ ABT_Stack_Size, 0x00000008 .equ FIQ_Stack_Size, 0x00000008 .equ IRQ_Stack_Size, 0x00000080 .equ USR_Stack_Size, 0x00000400
Iam facing the following problems 1. In my main(), I have a the following C statements
save_VicInt1 = VICIntEnable; //saving int status VICIntEnClr = 0xFFFFFFFF; // disable all interrupts flash_init(); //Initialize Flash and switch off PLL with sector n0: 19 flash_read_LMD_data(0x58000 ); flash_uninit(); //Unnitialize Flash and switch on PLL VICIntEnable = save_VicInt1 ; if((flash_LMD_data[0] & 0xFFFFFFFF00000000 ) != 0xDDDDDDDD00000000 ) { // Batt_RAM E0084000 *((volatile long long int *)( Batt_RAM )) = 0x0; //make End of battery //memory flash_LMD_data[0]=0xDDDDDDDD00000000; save_VicInt1 = VICIntEnable; //saving int status VICIntEnClr = 0xFFFFFFFF; // disable all interrupts flash_init(); //Initialize Flash and switch off PLL with sector n0: 19 EraseSector (0x00058000); ProgramPage(0x00058000, 512 , flash_LMD_data); //writing RTC connfig: //data to FLASH EraseSector (0x00068000); ProgramPage(0x00068000, 512 , flash_LMD_data); //writing RTC connfig: //data to FLASH EraseSector (0x00070000); ProgramPage(0x00070000, 512 , flash_LMD_data); //writing RTC connfig: //data to FLASH flash_uninit(); //Unnitialize Flash and switch on PLL VICIntEnable = save_VicInt1 ; } uart_init(); //read old LMD data from battery ram and write to FLASH copy_battery_to_flash(); //read all data from Flash and print in UART print_LMD_from_flash(0x00058000); // Batt_RAM= 0xE0084000 //make start of battery memory for storing Next set of LMD data from First *((volatile long long int *)( Batt_RAM )) = 0x0; //read old data from Flash for configuring the CAN save_VicInt1 = VICIntEnable; //saving int status VICIntEnClr = 0xFFFFFFFF; // disable all interrupts flash_read_LMD_ID(0x70000); //reading data from flash and put in a buffer //"flash_LMD_ID[4]" flash_read_sel_CAN_data(0x68000);//reading data from flash and put in a //buffer "flash_sel_CAN_data_2d[10][2]" flash_read_RTC_data(0x60000); //reading data from flash and put in a //buffer "flash_sel_CAN_data_2d[10][2]" flash_read_transmission_data(0x7B000); //reading data from flash and put //in a buffer 4 buffers to get ID,DATA,freq,port number VICIntEnable = save_VicInt1 ;
With the GNU settings for the compiler optimization set to LEVEL 1 the code goes to Abort mode if the last statement in the above code "VICIntEnable = save_VicInt1 ;" is executed. I checked the SP and found it to be within the defined stack boundary. I got this problem after I added a buffer "long long int flash_dest_var[2]={0};" in the function "flash_read_transmission_data(0x7B000);"
int flash_read_transmission_data(unsigned long adr) { unsigned long n,i,k=0; int data_count=0; long long int flash_dest_var[2]={0};
I have tried to increase the stack size but to no avail. If i declare this buffer "long long int flash_dest_var[2]={0};" globally then, i donot get this problem. Please kindly suggest a way to debug this problem.
2. In the second case, with the GNU settings for the compiler optimization set to "NO OPTIMIZATION" the code goes to Abort mode if the CPU is executing the function "flash_read_transmission_data(0x7B000);" in which i have declared "long long int flash_dest_var[2]={0};" . I checked the SP and found it to be within the defined stack boundary.
Please help me out with your valuable suggestions.
Also please can anyone brief me about the Optimization options settings which is present for the GNU compiler in the Keil uVision3 IDE.
Proberbly there is nothing wrong with your code or the variables in it. In the first revision of sillicon there was something wrong with the MAM. This results in jumping to the data abort handler. The cause depends on which code is placed on which address in flash.
If you only partially enable the MAM it will probably work fine. (see text from errata sheet below). The MAM bug is fixed in revision B of the sillicon
MAM.1: Under certain conditions in MAM Mode 2 code execution out of internal Flash can fail. Introduction: The MAM block maximizes the performance of the ARM processor when it is running code in Flash memory. It includes three 128-bit buffers called the Prefetch Buffer, the Branch Trail Buffer and the data buffer. It can operate in 3 modes; Mode 0 (MAM off), Mode 1 (MAM partially enabled) and Mode 2 (MAM fully enabled). Problem: Under certain conditions when the MAM is fully enabled (Mode 2) code execution from internal Flash can fail. The conditions under which the problem can occur is dependent on the code itself along with its positioning within the Flash memory. Workaround: If the above problem is encountered then Mode 2 should not be used. Instead, partially enable the MAM using Mode 1.
Hi, Yes I have checked with NXP and Rev.B of the chip is available. I shall try out with it.
I have observed the following things which i would like to bring to your notice as Iam really wondering if this could be a problem with the MAM
In the function which i have mentioned in my earlier posts i.e.,
Here, if i increase the the array size (i.e. long long int flash_dest_var[4]) to 4, then the code works fine. I mean it doesnot go to Abort mode.
Actually, we have USB codes integrated into our codes in which structure unpadding attributes are used. I have tried by removing USB codes and keeping the above mentioned array size to 2(i.e., long long int flash_dest_var[2]={0};). In this case also the code works fine.
So, is this a problem related to data alignment in the memory ? If so, how can one solve this problem. Kindly give me your suggestions.
The problem could be the data allignment in flash. As the text of the errata sheet in my previous says, the easiest way to test this is to set the MAM to "partially enabled" instead of "fully enabled". if your code with "long long int flash_dest_var[2]={0};" works ok than the problem was in the MAM. I had the same strange problems. When I added one line of code (for example, toggle a pin) in the function that ended up in abort mode, the code worked fine.
I'm using rev B now and everything is working fine now with the MAM fully enabled.