very strange issue on mcf5307

[angelo_d]

Dear all,

i am running the u-boot bootlader on mcf5307, everything works, until i enable timer2 interrupt for the clock.

After "rte" in the interrupt handler, cpu generate the following exception:

*** Unexpected exception ***
Vector Number: 3  Format: 04  Fault Status: 4

PC: 00fe910a    SR: 00002000    SP: 00ed8af0
D0: 00002c1b    D1: 0000001b    D2: 00400000    D3: 00ee8b76
D4: ffc12d08    D5: ffffffff    D6: 00ffad57    D7: 00ee8b76
A0: 00ee8b76    A1: 00fe9604    A2: 00ee8bc6    A3: 00ffd400
A4: 00ff8167    A5: 00ffbb00    A6: 00ed8b48

this code generate the exception:

_int_handler:

             rte   <-----

this code don't generate any excetion:

_int_handler:

            rts

It is incredible, manual says clearly that on exceptions, the top of the stack is not the return address but the longword with vector/format/status values. Since "rts" works, seems top of the stack to have the return address.

I am really stucked and can't realize the reason for this.

Any help is really appreciated.

many thanks

angelo

[TomE]

Is the address of "int_handler" the interrupt vector (in the vector table) and is "int_handler" declared with whatever magic the compiler uses to designate a function being the handler (so it saves more registers)?

If the code is working with an "RTS" then your "int_handler" is probably being called from another function (which is the "real" interrupt handler) or is being called from some assembly code in a file called "something.S" somewhere in the confusing U-Boot source tree.

Tom

[angelo_d]

Hi TomE,

thanks for the help, some time is passed from my last post  on the issue, since i updated the u-boot bootloader to the most recent "git" version to see if the problem disappear, how the u-boot list guys suggested me, but it's still there.

Well, i explain a little better how this bootloader works:

All the vector table (now in ram at 0x00000000) is initialized with "_int_handler" or "_exc_handler", depending if the vector is an interrupt or an exception. This is a common technique used to install later specific handlers at run time.

Timer 2 is on vector dec. 31 that is correctly initialized to "_int_handler" from a "trap_init()" function.

The assembly "_int_handler:" then call the proper interrupt manager function, now i have removed that code and let "rte" only.

From an objdump of the code, "rte" opcode is correct, i don't see nothing special in the code that can cause this strange cpu behaviuor.

One thing is clear, seems to be a "cpu" bad behavior, in an exception, stack frame should have the vector/format/status 32 bits information, and just after the return address, this tio have "rte" working properly. Instead actually there is the next return address in the top of the stack.

What i suspect is that the timer is set up wrongly, to a too short period, or something similar, that maybe two interrupts are triggered too near, or something similar.

I am going on today into investigation, any idea is really appreciated.

many thanks

regards,

angelo

[angelo_d]

hi all,

after some hard time in debugging the "u-boot" reloaction code, i finally found where the problem is, even if i still don't have any solution.

After the SDRAM initialization, U-boot relocate his code into SDRAM, with a memory copy, and after this operation set up a new stack (%sp) into SDRAM.

From the assembly line just after the new stack setup, i setup and start timer2 with interrupt, and the exception on " rte" happen from now.

Interrupt on timer2 was working properly with the stack still in internal ram (SRAM).

Anyway, C function calls / return running from SDRAM works properly, only when an interrupt happen, the "exception" stack fill-up is wrong.

Clearly this operation made from the cpu of preparing the exception stack frame don't work properly with SDRAM.

I am thinking that something in the SDRAM initialization code can be wrong, even if sounds really strange, linux run perfectly running from SDRAM, with this same initialization code.

every suggestion is welcome

regards,

angelo

[angelo_d · Accepted solution]

Hello,

finally, i solved it.

When a cpu behavior is strangely different from what the datasheet says (after reading it carefully many time), it worth a try to see the chip ERRATA:

MCF5307ER.pdf says:

35 : Corrupted Return PC in Exception Stack Frame

Using the workaround suggested (setting C/I bit of CS MASK register) solve the issue.

This explain why all other coldfire models works with the same u-boot code without issues.

Really hope this can help for who will have the same issue.

regards

[TomE]

Congratulations. That is a nasty one.

I'd take a good look at all the other errata items on that chip. It was truly unusable in the early mask versions, but there are still some errata items that could cause problems, such as (20). Can't you use a newer chip? That one is only 90MHz.

I'm comparing the memory control registers with the chip I'm most familiar with (MCF5329) and it only has "Address Space Masks" (including "C/I" the one that bit you) for the Static RAM. The MCF5307 has them for that, MBAR, Chip Selects and DRAM. These look like left-overs from its 68000 heritage. I don't think you want "C/I" space enabled on any of them.

Is this a bug in U-Boot? ((Google...)) I see from your post in June that you did the port. So you're responsible for it, the bug, the fix.

(( More Google...)) I do agree with Wolfgang, it is truly "stone age" :-):

http://www.mail-archive.com/u-boot@lists.denx.de/msg29004.html

Tom

[angelo_d]

Hi TomE,

after many year of experience in 8 bit cpu's, i decided to start a challenge for my first linux board, and chosed a Coldfire.

Then, since i like to start from small things to reach greater, i decided to start with one of the most simply chips where linux can run, just to make some experience. Also, since actually i solder all the prototypes here in my laboratory by hand, MCF5307 was available in QFP also . So i could succeesfullt have quite easy some protptypes:

http://194.177.99.211/~angelo/amcore.jpg

About the "stone-age", they was referring to the u-boot version, after updating to tha last git head. the bug was still there

Well infinite thanks for following my issue ! Hope i can be helpful to you also !

regards

angelo