rs485 Communication through usart

[aru]

Posted on April 27, 2013 at 08:12

I am using stm32f107rc for rs485 communication through usart1 and usart3. i am receving a set data from usart1 to an array and trying to transmit the same set of data from an array through an usart3. it works fine for while after that it enters in to the hard fault handler, so pls let me known where i am doing.... Thank in advance.....   

[Tesla DeLorean]

Posted on April 27, 2013 at 15:33

Well assume it's not a problem with the USART.

The processor stacks some of it's context, other data remains in current registers, and within the core. When it faults it does very specific things, and in order to determine what was going on you need to wind that back. Knowing where the code faulted, and the registers at the time you can make some educated guess about why that might have occurred. If you don't understand the flow of your code you can add checkpoints to confirm addresses or variables. A grasp of assembler will be helpful.

You need to review the TRM (Technical Reference Manual) for the core, along with Joseph Yiu's book on the Cortex-M3. Look at some of his Hard Fault Handler code examples.

Let's assume your problems are like most others, hard faults tend to catch gross errors, not subtle ones of logic or algorithms. As such they should be a lot easier to pin down and resolve. You need to understand where in your code they occurred, and what you were doing at the time. The predominant cause of hard faults are broken/invalid pointers, out of scope accesses, stack corruption, and the stack and heap colliding with each other. These can be tracked with asserts, or validation of structures at key points or periodically, adding guard zones and checking them. Expect the points of failure to be similar, either occurring at the same places (ie use of particular subroutines, or code), or while doing the same things (ie returning from a subroutine, use of particular pointers).

If the failure point appear random, consider if they occur immediate after an interrupt service, if those services exceed the available resources at the time, or interact with other tasks. Instrument the interrupt entry/exit so you can place them in the time line of the failures.

[aru]

Posted on April 29, 2013 at 07:38

[Tesla DeLorean]

Posted on April 29, 2013 at 16:10

I am using common array for receiving and transmitting the data... if i comment or disable the data array at receiving side it never enter in to the hard fault handler so pls let me known where i am doing mistake........

 

 

No idea, you'll need to learn how to debug. Leverage the faulting mechanisms within the core to pin point your failure.