NetBurner Community Forum

Hi,

I have a new custom board that I just received, and it has some problems. When plugging it into the internal 40-pin connector of my PK-70, the latter appears to be frozen. Specifically, at most only a single garbage character is emitted over the serial port, and a user LED on the side of the box fails to blink - as it should if my program is running.

Looking at the signals on the internal connector between the PK-70 processor board and my custom board, things look largely okay, but there are definitely some differences.

1. With the custom board (CB), the clock signal is a semi-noisy, but recognizable clock signal at ~11 MHz! Without CB, it is the expected 73 MHz clock signal as advertised. What could cause that? On the custom board, the clock only goes to an input on a Xilinx FPGA, where it is used to clock its circuitry.

2. With CB, R/W, *OE show apparent activity, but without, they are both high. Note that at this point, my software does nothing with the custom board. That seems weird! Should there be activity here?

3. The address lines seem to show normal activity in either case.

4. The data lines seem static, but differently. With CB, six are high, two are low; without CB, seven are low, one is high. There seems to be no activity whatsoever, though; shouldn't there be activity on these lines?

5. The three *CS signals are all high in both cases.

6. With CB, *TA is low; without CB, it is high; is this a concern? In other words, is this interfering with the processor?

7. With CB, *IRQ1 and *IRQ7 are at 1.8V, while *IRQ3 is at 3.3V; without CB, all are at 3.3V.

8. The miscellaneous I/Os (I2C, SPI, counters, etc.) are all high in both cases, except the MISO is low with CB.

Obviously, the clock signal is real weird, and I don't have any clues how that could happen - any thoughts?

Actually, I think it is *TA? But it raises a concern. IIRC, the MCF5270 data sheet says this is an optional signal, and the pin can be used as GPIO. Is this true, or does the PK-70 require it?

And should I, or should I not, see activity on the external bus signals (e.g. R/W, *OE, data, and address lines)? (Obviously, the *CSx signals should be high, as they are not being asserted, and that is the case.)

Thanks in advance,
-Bob

By default the clock PLL in the processor defaults to 1.5X the external crystal frequency. The external crystal is 14.5MHz which gives you a default internal clock of around 22MHz and external clock of 11MHz. Basically this says that the boot monitor has not been able to run out of flash and nothing has been initialized.

The TA signal is definitely a problem, what is holding it down? If you look at the CSCR register definitions in the chip select chapter of the reference manual you will see that an external TA signal will always supercede an internal TA from the wait states. When TA is held low all bus operations will have a wait state of 0. This will prevent flash and ram from properly working since the bus accesses are way faster then their timing specifications. It is true that TA can be configured for GPIO but the default configuration at boot is as the TA signal. You must be able to read code to the processor before changing this pin to a GPIO.

-Larry

You should probably cut the TA trace on your custom PCB to see if that corrects the problem. If it does not, then I would cut the clock trace. If your FPGA is somehow making the clock noisy then the processor will fail to boot. It is a good idea to have a clock buffer as close to the clock out as possible to prevent reflections on the signal. I have seen bad clock signal routing halt or reset the processor in past hardware designs. If you only route to an FPGA on a blade board you really should have not issues since there is only one short trace and no fanout. Still if your FPGA has electrical issues it may not be putting its pins in high impedance at boot.

lgitlitz wrote:By default the clock PLL in the processor defaults to 1.5X the external crystal frequency. The external crystal is 14.5MHz which gives you a default internal clock of around 22MHz and external clock of 11MHz. Basically this says that the boot monitor has not been able to run out of flash and nothing has been initialized.

I suspected there was a good explanation for that one, and that someone who knew the details (i.e. external crystal freq) would be able to explain! This is why these forums are such a great resource to your client community!!!

lgitlitz wrote:The TA signal is definitely a problem, what is holding it down? If you look at the CSCR register definitions in the chip select chapter of the reference manual you will see that an external TA signal will always supercede an internal TA from the wait states. When TA is held low all bus operations will have a wait state of 0. This will prevent flash and ram from properly working since the bus accesses are way faster then their timing specifications. It is true that TA can be configured for GPIO but the default configuration at boot is as the TA signal. You must be able to read code to the processor before changing this pin to a GPIO.

Yeah, had a hunch on that one. I had an issue before on another board (using a MOD5234 that time) when I tried to use TA for its intended purpose. When I couldn't quite get the FPGA code correct to use it, I realized a wait-state or two was not in any way a performance problem, so decided to do without. But then I made the mistake, and simply set it low; I think I thought it was an AND thing, or something. Anyway, I set it high, and forgot about it - until I read your reply...

Anyway, I cut that trace, and the processor is fine. That signal was indeed being actively driven low, on purpose, but only because of its intended GPIO-related function. Fortunately, I'm able to live without that function for now, and can reassign another GPIO for the intended function, if it is needed.

Thanks for the help, Larry!
-Bob