Help w/ Bus Error with MCF5213EVB Please!

[Sprtng]

Hi, I've been programming a lcd, upto this point it all worked until i made modifications to the line 1038 in main.c, the case 1 of the switch statement is same as case 0; case 0 works perfectly, but when i take out the commenting on the case 1, it does not work for some reason and gives me a bus error. Has anyone gotten this problem? Thanks a lot!

Tong Yin

attached is the project file

evbdata.zip

Message Edited by t.dowe on 2009-10-21 02:24 AM

[Sprtng]

Hi, sorry, that was not a most recent copy..this one. i made some changes last night, but still couldn't get it to pass the bus error, it appears once you take out the comments in line 870 to 873, which is very wierd because case 0 of the same switch statement works perfectly which is identical to case 1.. Thanks for your reply!

evbdata_update.zip

Message Edited by t.dowe on 2009-10-21 02:20 AM

[mccPaul]

Hi

It is difficult to see why the code would work when the if statement is commented out but it may be being caused by not setting the interrupt priority for each ISR and I am not sure if you are able to guarantee a single interrupt for each button release. Could the system be interrupted multiple times for each button release?

Interrupt priorities: there are 7 levels and 8 priorities in each level (see section 12.1.1 in the mcf5213 user guide). You must set each ISR to a different priority (see section 12.3.6). This is may not directly be causing your problem, but you should address this.

Presumably the fault occurs the first time that code is run, which implies that ii occurs the first time the button_down ISR is called - is there anything different between the way this interrupt is generated compared to the button_up one?

Sorry that I can't offer a solution but I hope these ideas help.

I have included the code I use to set up ISRs for the 5282, which may be useful.

Paul.

Code:

void mcf5282_interrupt_init(uint8 source, uint8 ipl, void (*handler)(void)){ // Only for user defined vectors in INTC0 if ((source > 0) && (source < 63))  {  // Interrupts should be disabled to avoid vector problems  // and to ensure that a spurious interrupt exception can't  // be generated.  uint8 sysint = asm_set_ipl(7);  if (handler)  {   // Set interrupt priority level   MCF5282_INTC0_ICR(source) = (ipl & 0x3F);       // Set vector   mcf5xxx_set_handler(source+64, (ADDRESS)handler);    // Clear mask for this handler   if (source < 32)    MCF5282_INTC0_IMRL &= ~(MCF5282_INTC_IMRL_INT(source)          | MCF5282_INTC_IMRL_MASKALL);   else   {    MCF5282_INTC0_IMRL &= ~(MCF5282_INTC_IMRL_MASKALL);      MCF5282_INTC0_IMRH &= ~(MCF5282_INTC_IMRH_INT(source));   }  }  else  {   // Set vector   mcf5xxx_set_handler(source+64, (ADDRESS)handler);    // Set mask for this handler   if (source < 32)   {    MCF5282_INTC0_IMRL |= MCF5282_INTC_IMRL_INT(source);   }   else   {    MCF5282_INTC0_IMRH |= MCF5282_INTC_IMRH_INT(source);   }  }       // As you were...  asm_set_ipl(sysint); }}

 

[Sprtng]

Hi Paul,

I dont quite get the whole IRQ issue, seems like the errors i am getting now is not related to it somewhat.., i was about to use polling a port instead. This time the error is some what different..

it happened in line 503, in the big switch statement.

If I have more than 10 cases, it goes bus error on me, but if I have less than 10, it works perfectly.. and If I have 16, which is all of them, then it goes overflow...could you explain to me what is causing this?

I really appreciate what you have done, Thank you a lot!!

Tong 

evbdata.zip

Message Edited by t.dowe on 2009-10-21 02:19 AM

[mccPaul]

Hi Tong,

Again, I don't see any problem with your code, which makes me suspect that the problem happens because of the way the system is responding to your code.

What exactly do you mean by 'bus error' and 'overflow'? Are you seeing errors output on the console?

You can eliminate any problems from the ISRs, or the way that your IRQs have been set up by commenting out all of the calls to mcf5xxx_set_handler() in main(). Also remove the __interrupt__ modifier from your ISRs. Now add a few lines to main which will call the different handlers like so:

Code:

// Insert this before the while loop in main()button_down();// Pause 1 sec (not required if you step through with the debugger)cpu_pause(1000000);button_down();cpu_pause(1000000);// and so on.

 
This will allow you to test your ISRs without having the interrupts set up. If the handlers now work properly then you must suspect that the IRQs are not properly configured. You can either fix this or change to poll the port.

If this code also fails, then I suggest that you remove the code that initialises gpio, lcd, etc., step by step, until the switch statement works. You may also need to comment out code from the write() function if your lcd is not initialised. When the switch statement is working, add the code back line by line until it fails again - you should then find out what is causing the problem.

Paul.

[Sprtng]

Hi Paul,

thanks for your reply again! As you suggested, I tried to comment the mcfxxx part out, and call the interrupt handlers directly. However, it seems it always stops at the 2nd interrupt function call, doesn't matter which interrupt function call it is, and gives me an Format error, I searched for format error on the forum, and couldn't find anything related to it. But fortunately, the switch statement works fine now. 

Regards,

Tong 

[mccPaul]

Did you remeber to remove the __interrupt__ qualifier from the ISR definitions?

If not, you will get a format exception. Before the ColdFire call an ISR it creates an exception frame and pushes it onto the stack. The __interrupt__ qualifier tells the compiler that the return instrcution for this routine should be an RTI assembly instruction instead of the ordinary RTS instruction. The RTI instruction uses the exception frame on the stack to work out where to return to.

If you call the ISR from your code, the compiler generates a JSR assembly instruction to call your function. JSR does not push an exception frame onto the stack so when you reach the end of the ISR the RTI instruction tries to interpret the data on the stack as an exception frame. Usually the data on the stack is not properly formatted so you get an error.

If you want to create an ISR that you can call from your code, it is easiest to create a normal function to do the work and to call that function from the ISR. See the snippet below.

Code:

__interrupt__ void test_isr(void){  ...  // Call worker function  do_work();}void do_work(void){  // Do something  ...}

 

[mccPaul]

Hi

Did you attach the correct files? The main.c does not have line 1038 and there doesn't seem to be a problem with the only switch I can see in the source.

Paul.