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.
Hello all,
I am developing a project using the LPC1752 and uVision 4.10 on my own hardware using the FatFS library. I am having a problem whereby the order in which I declare my variables seems to determine whether or not the code causes a hard fault or not.
I my main.c file, I have declared two global variables:
FATFS fso; char ReadData[512];
My test code simply creates a file on the SD card, writes some data to it and then reads the data back into the ReadData array. With the variables declared in the format shown above, my code works fine. However, if I swap the declaration to this:
char ReadData[512]; FATFS fso;
The code generates a hard fault. I have examined the Fault Reports dialog in uVision and it has shown me that the INVSTATE bit is set. According to the call stack, the fault has occurred at the end of my SDReadBlock function, just as I am returning a value. Here is a snippet of the function where the fault occurs:
// Read the 2 CRC bytes SPIWrite(0xFF); SPIWrite(0xFF); CSHigh(); SPIWrite(0xFF); return SDOK; //<== Here is where the call stack is pointing to }
The corresponding assembly code is:
370: // Read the 2 CRC bytes 0x00002E6E 20FF MOVS r0,#0xFF 0x00002E70 F000F924 BL.W SPIWrite (0x000030BC) 0x00002E74 F8050B01 STRB r0,[r5],#0x01 0x00002E78 9800 LDR r0,[sp,#0x00] 0x00002E7A 1E40 SUBS r0,r0,#1 0x00002E7C 9000 STR r0,[sp,#0x00] 0x00002E7E 9800 LDR r0,[sp,#0x00] 0x00002E80 2800 CMP r0,#0x00 0x00002E82 D1F4 BNE 0x00002E6E 371: SPIWrite(0xFF); 0x00002E84 20FF MOVS r0,#0xFF 0x00002E86 F000F919 BL.W SPIWrite (0x000030BC) 372: SPIWrite(0xFF); 373: 0x00002E8A 20FF MOVS r0,#0xFF 0x00002E8C F000F916 BL.W SPIWrite (0x000030BC) 374: CSHigh(); 375: 0x00002E90 F000F8E6 BL.W CSHigh (0x00003060) 376: SPIWrite(0xFF); 377: 0x00002E94 20FF MOVS r0,#0xFF 0x00002E96 F000F911 BL.W SPIWrite (0x000030BC) 378: return SDOK; 0x00002E9A 2000 MOVS r0,#0x00 379: }
What could be causing the problem?
--Amr
Hi John,
Thanks for the pointer - it looks like that was the culprit. I've increased the stack size and now the program is working. Thanks for your help!