This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM ABORT mode problem

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.

  • Do you use the MAM? and in which mode?!

  • Hi, i need help on MAM. The code Iam using has the
    MAM related code defined as follows:

    .equ    MAM_BASE,       0xE01FC000  /* MAM Base Address */
            .equ    MAMCR_OFS,      0x00        /* MAM Control Offset*/
            .equ    MAMTIM_OFS,     0x04        /* MAM Timing Offset */
    
      .equ    MAM_SETUP,      1
            .equ    MAMCR_Val,      0x00000002
            .equ    MAMTIM_Val,     0x00000004
    
    
    #Setup MAM
    .if MAM_SETUP
                    LDR     R0, =MAM_BASE
                    MOV     R1, #MAMTIM_Val
                    STR     R1, [R0, #MAMTIM_OFS]
                    MOV     R1, #MAMCR_Val
                    STR     R1, [R0, #MAMCR_OFS]
    .endif
    
    
    
    # Memory Mapping (when Interrupt Vectors are in RAM)
    .equ    MEMMAP,      0xE01FC040 /* Memory Mapping Control */
    
    .ifdef REMAP
                    LDR     R0, =MEMMAP
    .ifdef RAM_MODE
                    MOV     R1, #2
    .else
                    MOV     R1, #1
    .endif
                    STR     R1, [R0]
    .endif
    

  • 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.,

    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};
    


    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.