• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 489 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CAN module erroneously initialized from startup ?

Jens Lauer
Prodigy 150 points

[LM4F232 Eva Kit + CodeComposerStudio 5.3]

short question - long story:

 

I have had some trouble with timer initialisation for some long time. The error was not reproducable every time, but if once I got it it seemed to be some reflash with other application needed before it was willing to go.

I have four wide timers in my app and always when wtimer1 was involved with (MAP_)IntEnable( INT_WTIMER1A ) the system crashed.I observed the FaultSR and found the processor jumping in. So I remembered have read such stuff before and follewed the - very good - advices in SPMA043.pdf (Diagnosing Software Faults in Stellaris Microcontrollers).

The adress by bus error coming from was 0x40040020 which I cannot find directlyin the cortex-M4 processor's memory map. But the region nearby is:

"0x4004.0000 0x4004.0FFF CAN0 Controller"

So I moved the init code regarding CAN0 so now it's located before Timer's init and this avoids crashes. I interprete this fact as getting some garbage (maybe  from external CAN transceiver ) into the CAN controller before I have enabled it.

But how could this be true? Every module should be disabled at init/reset, is'nt it? The cortex M4-F errata gave no hints regarding this.

Thanks for any hints.

--jens

 

 

  • 0
    Genius 5695 points

    Position sensitive code is nothing new in compilers -- nor is it new with low level programming.

    Did you do a peripheral rest for the CAN? I have not looked to dsee if it is possible. But... that also solves certain issues with I2C -- to issue a peripheral reset before attempting programming of the I2C unit.

    I would be curious if that made a difference -- even if nobody else.

  • 0
    Guru 117855 points

    Plz check the following:

    a) have you properly, "SysCtlPeripheralEnable()" w param. "SYSCTL_PERIPH_WTIMER1" prior to your, "IntEnable?"

    b) has your Start-Up file properly placed your interrupt handler @      // Wide Timer 1 subtimer A - rather than the earlier listed, Timer 1?

    If "yes" to both - try swapping the code locations of one of your successful wide timer, "IntEnable" functions with failing WTIMER1A.  Does anything change?

    Such Fault usually results from missing or incomplete enabling of each/every required peripheral - prior to that function call.  Unclear as your meaning re: "system crashed!"   Do you mean that your code properly compiled and linked - and then when downloaded and Run - that it behaved improperly?  Kindly detail...

  • 0 in reply to cb1_mobile
    Prodigy 150 points

    I am aware by this mantra-like advice "call SysCtrlEnable before" for a long time because I already was fallen into this trap - so I was warned. Every usage of core-externals in my code starts with SysCtrlEnable, followed by SysCtrlPeripheralReset. OK, I am not consistent here - in older code I was using xyzEnable -> xyzReset -> while false == SysCtrlPeripheraReady. In newer times especialy for Timers I changed to xyzEnable -> xyzDelay -> XYZReset -> xyzDelay -> TimerDisable -> TimerConfigure -> ... ->TimerIntEnable -> IntEnable -> TimerEnable with delay values of about SysClockGet()/50 ...

    Every handler is properly placed in startup file. Timer means in tat case Wide-Timer. None-wide-timers were excluded using #ifdefs.

    I already had extracted every timer's IntEnable as well as the TimerEnable's, so I was able to play with code locations. When I changed the location of IntEnabl(WTimer1A) always after it's location it crashed.

    "Crashing" means the debugger scope disappears and FaultISR handler gets called. 

    Some deviations were observable: depending on location of breakpoints sometimes the "crash" came one ore two lines later when I was calling IntPrioritySet() or TimerEnable(). But neither I could derive some rule from this nor I checked the FAULTADDR ( 'cause it was before I read SPMA043.pdf ).

    Now speaking again about the new situation where I moved CAN related code prior to WTimer related:

    @Dave

    I checked the code regarding CAN init and I also call SysCtlPeriheralEnable followed by SysCtlPeripheralReset. The only one suspicious was that I have no delay between enable and reset ...

    Perhaps I will collect all my enabled peripherals and enable and reset them prior at some early stage of the system-init so they have enought time to wake up properly..

    For now - with this move -  the problem seems to have gone. I will observe this further, anyway.

    Thanks so long.

     

    --jens