ColdFire 5213 w/o MULTILINK pod

[jes]

Hi,

My application code runs fine with the P&E Micro Multilink pod but will not run without the pod attached after POR, or at least it appears that way since it won't communicate serially.  This is true of both the eval board and our own board.  However, on the eval board, if you hit the reset button then the code will execute.   One engineer suggested from previous experience that it was an initialization code issue but couldn't locate the exact problem.  Documentation isn't clear on conditions on POR vs. hardware reset.

Is anyone familiar with this issue that could describe steps necessary at initialization to ensure processor runs without the pod?

Thanks,

Joe S

[jes]

Answering my own question a bit.  From what we've found it looks as though there may be a problem with the logic of this particular 5213 processor depending on the reset condition (unless someone can offer an explanation otherwise). 

When a power cycle (POR) occurs, an exception is apparently thrown for the watchdog timer even though the initialization code does not or has not enabled the watchdog.  The exception occurs at approximately 11 milliseconds following reset (note that this doesn't jive with the 2^9 default value of period in SCM CWCR register but we're thinking there is a prescalar somewhere).  I noted this exception by having just by luck to have cycled power with the pod attached (same condition applies as without the pod and power cycle) and then hit break.  The code was sitting in the function uart_putchar() that came with the eval board waiting for the uart to signal it was ready for another char to transmit.  This function is called as part of printf() which attempts to spit out a message describing the exception.  (Why the uart never becomes ready is another question, perhaps related to not yet being enabled out of POR.  Why it's sending characters to uart in an exception handler is yet another question.)  Sitting at this function while in the exception handler effectively kills all other processing.

I also traced the frame pointer to a value of 0x411c2009 which is FORMAT 4 and vector 71, the watchdog timer. The debugger also shows bit CWTIF in CWCR as 1, indicating watchdog interrupt has indeed occurred.  The CWCR value is 0x01, also indicating the watchdog isn't even enabled!  So what faulty logic has caused it to occur?

I can circumvent the error by putting a return statement in uart_putchar() rather than the existing while statement.  No further watchdog interrupts occur, indicating that it may have indeed been spurious.  This is as we would expect since CWCR hasn't enabled watchdog.

Note that, as mentioned previously, hitting the RSTI line while in this faulted state resumes normal behaviour.

[jes]

Some more info.  It also looks as though on a POR that the UART may not function correctly either unless certain actions are taken, see below.  (Not sure whether it's just the transmitter or the receiver as well.)

This would account for the uart_putchar() function associated with the watchdog exception waiting indefinitely for UART to indicate tx ready.  However, if a SOFT RESET is issued to Reset Control Register (RCR)after having recognized a POR via the Reset Status Register (RSR, bit 3) then the UART functions correctly.

I'm reluctant to believe these problems could really exist and I might be overlooking something that could be accounted for in faulty initialization code that came with eval board since these seem to be major issues.  (But this reluctance is somewhat relieved by the fact that this is I think a fairly recent flavor of uP constructed with an amalgam of other blocks.)  Am I crazy or has anyone else noticed the same behaviour?

[JimD]

I am getting an error on the uart_putchar(), it give the error Reserved #5 (MCF5XXX_RD_SF_VECTOR).

I am reading and writing values to the same UART. I need to poll for a key to change the setting. I need data to written to the screen (printf) while I wait for a key hit.

The uart fifo doesn't seem to work right I can get the same
character out of the receive UART FIFO over and over again. It never clears the value. I wonder if you have found a problem that the uart is comming up scrambled. I tried to do a reset of the uart and it just hangs.

What is the best way to get the UART reset. This isn't brain surgery I was doing this on a Commodore64 30 years ago and it worked.

As someone who is a C Programmer I hate to say this. Does anyone have and assembly code to get the UARTS under control untill they fix the compiler



Codewarrior 6.3 built 14
Latest Headers

[jes]

The only way we got the UART to behave correctly out of a POR is by doing what I described in an earlier post.  A freescale field engineer had the same problem at one time and swore it was a h/w issue out of a POR, as did we.  However, the FE said he incorporated newer initialization code and the problem mysteriously disappeared.  We tried the same initialization code and the problem persisted.  I sent FE my project so he could examine and alter but haven't heard back.

In the meantime, the only way we were able to avoid the UART hanging out of POR is to:

1.) After a POR, examine the Reset Status Register (RSR). 

2.) If RSR indicates a POR then perform a SOFT RESET.

3.) The UART then works correctly after the SOFT RESET.

Note that while debugging in CodeWarrior, the UART problem required that we start the code running an initial time, STOP, then reload again.  The UART then behaved correctly.

You could get the equivalent of above SOFT RESET by also hitting the RSTI pin on the eval board, if that's what you're using.  We were spitting an announcement message out the UART on power cycle.  If we didn't SOFT RESET as above on power cycle then no message.  If we hit RSTI w/o SOFT RESET we got the message.  With SOFT RESET we get the message as well.

NOTE:  There are a number of 'gotchas' on this part particularly due to inaccurate or incomplete documentation.  Erasing and writing Flash posed another hurdle because of this.  Caveat Emptor.

[zkwayne]

When you run the code with the pod the debugger runs a start-up script to do the initialization. I would suggest looking at this script and make sure your startup code does everything the start-up script does ...

[PaoloRenzo]

Just use this project template:

http://www.freescale.com/files/netcomm/software/app_software/code_examples/MCF5213SC.zip

This way you'll be able to use printf even after a POR.

Good luck!

[jes]

Thanks for reply.  What is the typical name of start-up script?  Is it the .cfg file?  The contents appear below.  It's nothing extraordinary and is already being done within initialization code although not in consecutive instructions as appears below.

ResetHalt

; Set VBR to the beginning of what will be SRAM
; VBR is an absolute CPU register
writecontrolreg 0x0801 0x20000000

; Set RAMBAR1 (SRAM)
writecontrolreg 0x0C05 0x20000021

; Set FLASHBAR (Flash)
writecontrolreg 0x0C04 0x00000021

; Enable PST[3:0] signals
writemem.b 0x40100051 0x0F

Does the PIT0 timer (the one I'm using for my system clock tick) have any unusual operation that is not touched upon in the MCF5213 Ref Manual that precludes it from working without emulator under certain circumstances?  I've set PMR Modulus register with a value of 0x7d0 (64 MHz clock) to count 1000 Hz.  PCSR is set to 0x040f.  I'm grasping at straws since we can't determine the cause of inoperability.  If you hit the RSTI line then things operate correctly but POR yields incorrect operation.

[zkwayne]

The name of the start-up script would depend on the debugger you are using.

I am not that familiar with the 5213. Several years ago I helped bring up our 5407 based board. At that time there was an application available from Free Scale that generated the start-up code. We used the application and then tweeked it for our board.