Hard fault Exception when bus fault exception occured

[mahapushpa]

Posted on December 31, 2012 at 19:28

Dears,

I have problem while debuging the code for STM32L151RDT6. I get every time the hard fault exception with bus fault. Description of Project: I am using KEIL 4.54 with ST Link/V2. The system has SPI FLash (8MB from winbond), uses embedded Flash file System without RTX. The stack size is 2K and Heap is 1K. The startup file have not changed except the sizes as above mentioned, supplied by KEIL along with compiler. I uses ADC1 and USB(Device), USB_LP_IRQ along Systick in application. I have assigned the Priority group1 with ADC1 (0,0) and USB (0, 1) priority (Prempt priority, sub priority). FOr USB, I uses CDC class and send the packets of 64 bytes. As long I read the settings from RAM, I do not have any problem, but whenever I send the command to read the stored file in SPI flash, I get the problem while opening the file. While reading on internet and blogs, book by Joseph Yiu. I got confused and did not able to find real reason. I included the screen shots of code, registers and other things whatever possible. Pleae let me where is problem, what is going wrong with code which generate the exception and system goes out of order(Do I need RTX with file system?) Explanation of pdf file 1. Page one show the status while entering in the main program. 2. Page two, has break point on fopen command, which generate the problem. 3. Page three, has subfunction fopen (library of KEIL) 4. Page four, status of system when Exception occured. Below is c statement of file. I also get the same exception some time, in this case, also it is by fopen command (to append the file). In stated case, I get problem 100%. The bus fault error address is out of address range, which is not understandable. FFS_EXTERN  void  FFS_vReadFile(char *par) {   FILE *f;   char *fname, *next;   ulword    ulSize;   char aubText[68];        fname = get_entry(par, &next);   if(fname == NULL)   {     KEY_vMSGDisplay2(KEY_FILE_NAME_MISS);     strncpy(aubText,''File Name missing.\n\r'', sizeof(aubText));     USB_vTxmtString((const char *)aubText);     return;   }   f = fopen(fname, ''r'');            /* open the file for reading          */   if(f == NULL)   {     KEY_vMSGDisplay2(KEY_FILE_NOT_FOUND);     strncpy(aubText,''File not found!\n\r'', sizeof(aubText));     USB_vTxmtString((const char *)aubText);   } so on further.

[Tesla DeLorean]

Posted on January 01, 2013 at 02:03

Page 4 does NOT show the branch target for the code marked in Page 3. It shows you in the Hard Fault handler, not the code that FAULTED, presumably based on your description 0x080007E2, or somewhere thereabouts.

The precise fault address suggests you are touching some memory around R0 or R4, but you aren't displaying any of the stack content or faulting code, so it's all rather conjecture. Also, I'm not suggesting you merely expand the stack to see if the problem goes away, but rather measure the actual maximal usage. It currently looks as if you are passing some invalid, or uninitialized structure, and it Hard Faults as you touch some memory inappropriately. Again, you debug this by looking at the failing code, and the processor state when the fault occurred.

[mahapushpa]

Posted on January 01, 2013 at 11:56

Dear Clive1,

I have done again testing and attached the screen shots of problem in details. It looks that address in R0/R4 is going wrong and it happens whenever there is call of fopen function. 1. In page one, debugger break on call of fopen library function (address 0x080007B0, same time there is values of address, SP, LR etc. It looks ok. 2. In page two, while using Stepping, I able to go till the address 0x080007BE, which is jump to back on address 0x080007B0 (I did not understand jump back in this function, anyway it is keil lib, so i assume it is right or needed). 3. Page 3, next step back to address 0x080007B0 and state of registers, PC, SP, LR and other things. 4. Page 4, landed by next step in page. (i.e. bus fault with hard fault) with fault reports. I hope that I have given the fault code or place from where this problem occurs. While analysis the code, It looks that 0x080007BA line creating wrong value in R4 and line 0x080007B0, loading this value in R0, which is address and it is out of range. Still it is load only, it is not any call, should not give create problem. While Reading the book (Joseph) page 351 (bus fault status register), it say that bus error during data access. The fault address may be indicated by BFAR which has 0x00002A6C which is not part of STM32L It also indicate that error could be caused by a device not having been initialized, access of privileged only device in user mode or the transfer size is in correct for the specific device. To catch further, I need your help, what can be meaning here device, or transfer size and how to see which mode is suitable for fopen command. I am embedded FS, does it need fix length file name (just trying to co-relate with above transfer size). Let me know your thought on it. ________________ Attachments : hard_fault.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtUg&d=%2Fa%2F0X0000000aQn%2FEFDF6KRtRNo3FrRXX2IZlkcGmDjBEVtGNYSDHzFcNYI&asPdf=false

[Tesla DeLorean]

Posted on January 01, 2013 at 17:41

It looks a bit like the 0x080007AE LDR R4,[PC, #64] is loading an inconsitent value from 0x080007F0, the subsequent LDR R0,[R4, #0x4C] is faulting.

You could check the correct literal value that is stored at 0x080007F0 You should probably check the frequency the core is running at, the voltage, the flash wait states, and flash prefetch settings.

[mahapushpa]

Posted on January 15, 2013 at 19:49

Dear Clive1,

Still, the problem is not solved. I have changed my user source code to make sure that I am not making mistake, checked code with PC-lint also to make sure any static problem. I found one things. I get exception whenever there is request from PC via VCP. That means, if transfer the data after power on, to PC using system(my device) using local keys, it open the file and send the complete file, no exception, but I read any thing from PC and do above exercise, it give the hard fault exception with fopen function. It looks the any traffic from PC on VCP, is creating the problem, either killing the File info etc used by fopen function. Any Clue to check in debugger.

[Tesla DeLorean]

Posted on January 15, 2013 at 23:20

You need to look at the literal value it is loading, confirming that the in memory value is correct.

If the literal is not being read consistently you need to look at the clock and flash prefetch/wait-state setting. If the literal has the wrong compiled value you need to look at what the compiler and linker are doing. LDR R4,[PC, #64] ; << LOOK AT THE LITERAL STORED AT PC+64 LDR R0,[R4, #0x4C]  ;<< THIS FAILS WHEN HIGH ORDER 16-BIT IN R4 ARE ZERO

[mahapushpa]

Posted on January 19, 2013 at 12:50

Dear All,

Thanks for your suggestions and spent time. Finally the problem has been fixed. It was not null pointer problem, but corruption of Stack and Memory area by for loop. In USB receive function, I used to stripped all the unwanted bytes in received message including CR and LF(keeping space, alphabets). The file system functions, before executing it, convert the received message to upper case using one general function (taken from KEIL example code, char *get_entry(char *cp, char **pNext)). In this function, // convert the string to upper case   for (sp = cp; *sp != ' ' && *sp != CR && *sp != LF; sp++)   {     *sp = (char)toupper (*sp);                /* convert entry to uppercase  */   } breaks with space, LF or CR, which were not part of command to read the file READ FILE_NAME. This for loop create problem in RAM by converting to them upper case till that it do not find either of above three characters. After including the LF/CR in message, it terminate as expected and problem solved. I say, some time changes or optimisation leads blunders as I have optimised the receive function but missed the impact in conversion. Still I request to all, the conversion should have this break condition also so that any String can also be send for conversion without impact and fully occupied RAM.

[Tesla DeLorean]

Posted on December 31, 2012 at 19:52

You need, perhaps, to use one of Joseph Yiu's example Hard Fault handlers, and get clear and decisive information about the location of the faulting instructions and the register content at the time.

You show a branch, but not the target it goes to. Are you sure the stack is adequate? How much of it are you currently utilizing? Consider looking at how deep it gets (dynamic analysis), and how much local/auto space your variables are taking up (static analysis). When in the Hard Fault you need to examine the stacked state of the processor, so figure out which of the stacks was used, and then look at a memory view of it, a 32-bit unsigned long view might be ideal. Driving the debugger in this state is an interactive task, a couple of static screen shots probably isn't going to help. You want to be looking at registers, looking at disassemblies, and drilling down into other memory locations.

[mahapushpa]

Posted on December 31, 2012 at 20:17

The branch shown in page 3 where as destination is shown in page 4 which is hard fault exception handler of stm32l1xx_it.c file comes along with compiler examples. Same I have also given values of each registers. The MSP stack used, as per stepping, I feel that stack is sufficient (I have 2K, even tried till 8K, have same problem).