Hello, I am using tm4c123g microcontroller(cortex m4) and successfully programmed led blink, created 16x2 and 128x64 library files using CMSIS standard. But when I try to write any value in UART register, it causes the cpu to jump into hard fault. Example UART0->CTL&=~1; triggers the hard fault handler. I am facing this problem with all other UART registers like baud registers.
BTW I am able to do it with direct memory addressing. But I want to use UART funcions in CMSIS. I don't know what's going wrong please help.
Have you tried debugging the Hard Fault to see what, exactly, is causing it?
www.lmgtfy.com
The TM4C is a Texas Instruments (TI) product range. For specific details of what could cause that particular product to Hard-Fault, you should be asking TI.
One thing to check would be whether the UART is properly enabled & ready to use:
- bus interface enabled?
- peripheral clock(s) enabled?
- etc...
Thanks for reply.I tried to debug that fault but still got nothing.The initialization rituals are given in the datasheet and i am following in the same manner.When i write the values using CMSIS standard it triggers the hard fault, but when i use direct memory addressing in the same manner it works fine.So in my opinion it is not something related to unlocking or clocking the IO.
BTW I am going to ask TI too.
Debugging includes verifying exactly what addresses your code tries to access using the two methods. And that should have told you what would differ between direct addressing and indirect addressing using the pointer. But it sounds like your form of debugging was to test run and deduce "works" or "fails" instead of figuring out what actually differs.
Don't forget to post links between your two threads!
Start by looking at the thread, "Diagnosing Common Development Problems and Tips for TM4C Devices"
e2e.ti.com/.../374640
In particular:
ISSUE#2: After Enabling the Peripheral, the program goes into FaultISR
ISSUE#6: Code goes to FaultISR..
"BTW I am going to ask TI too."
What are you going to ask TI about? How to debug? If you use a header file from them, and you find that they have a constant wrong, then it's meaningful to contact them. If you, on the other hand, is using the header file for the wrong processor then it's way better to figure this out and fix it instead of wasting the time of the TI engineers.
I have got the solution. The base address for UART0 register was wrong in the controller header file. The CTL was pointing to the wrong address.
Thanks to all for helping.
Now that is something that you should be reporting to TI!!
It would also be helpful if you would post here exactly what is wrong, and exactly how to correct it - for the benefit of others who may run into the same problem
This could be the result of the UART peripheral not being powered.
"I have got the solution. The base address for UART0 register was wrong in the controller header file."
This was the first thing I told you to check. And you still came back and told us you had debugged but not found anything...
Next step now is to verify if it was the chip manufacturer, Keil or maybe the board vendor who supplied the header file. And if it was the most recent version of the file that you used - this kind of errors normally gets quite quickly corrected since they are so quick to find when someone tries to actually make use of the file. It's the seldom used rare configuration flags that may survive for a long time with incorrect values since no one is actually using them - or verifying that they did take effect as intended.
Should, of course, say:
"you should be reporting to the author of the file" - which may or may not be TI...