Hello,
I recently updated to 8049 from 6852 version of Stellaris Peripheral Driver Library. I am using LM3S5R31. The problem is that the program gets reset because of a FaultISR. I traced the problem to IntEnable() in interrupt.c of this new library.
It would be highly appreceiated if anybody can give me the following inputs.
1. What are the precautions that to be taken while updating the Peripheral Driver Library.
2. Any solution for the above problem?
Thanks in advanceRajan
Rajan,
Are you running the exact same code that you ran in version 6852?
It is most likely not IntEnable(), but you trying to access a peripheral that hasn't been enabled.
Use the following document as a reference for debugging a fault:
ARM TRM: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf
Section: 5.5.1 Stacking
This section will give you the state of the stack after the exception, allowing you to debug the fault.
Regards,
Alex
Of course - do follow the guides of Stellaris Alex. Perhaps - there may be a slight change in function definition and/or parameterization - between your old and current versions of StellarisWare. Beyond IntEnable() suggest that you check MasterIntEnable() and other, similar peripheral interrupt enables & set-ups.
StellarisWare team does a really good job of insuring compatibility from version to version.
We've encountered similar problems @ clients - several times the code had been "tweaked" - would no longer run fault-free - even when rolled back to the prior version of StellarisWare - yet the newer version was "blamed." Wise to confirm that the exact code you are now using does indeed run properly on older StellarisWare...
Thanks for your inputs.
Yes, the exact same code worked with the old stellaris driver library. Today let me try to exactly pin point the error and update.
My guess is that your your startup code no longer includes the links to your interrupt handlers. The default interrupt handler is the fault ISR. Check the startup_xxx.c file (where xxx is replaced with something appropriate for your tool suite).
Wow.... As usual the problem was in my code.
It worked with the old library (in rality it was not!) as the IntDisable was something like this
else if((ulInterrupt >= 16) && (ulInterrupt <= 47)) { // // Disable the general interrupt. // HWREG(NVIC_DIS0) = 1 << (ulInterrupt - 16); } else if(ulInterrupt >= 48) { // // Disable the general interrupt. // HWREG(NVIC_DIS1) = 1 << (ulInterrupt - 48); }
It failed in the latest library because the the code is as below.
else if(ulInterrupt >= 16) { // // Disable the general interrupt. // HWREG(g_pulDisRegs[(ulInterrupt - 16) / 32]) = 1 << ((ulInterrupt - 16) & 31); }
Awrong number was sent (port number instead of interrupt number) and the register number in the above code ( HWREG(g_pulDisRegs[(ulInterrupt - 16) / 32]) = 1 << ((ulInterrupt - 16) & 31);) WRONG and hence the exception/faultISR