Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Wade,

If you are getting the "done" light on the part, then the FPGA is loading correctly and it's 99.99999999999% likely a logic, or more likely a logic reset condition in the code. I only say this because we have never had a problem with configuration errors or corruption on any MityDSP-L138 (or any other Xilinx design, really) once the configuration stream enters the "done" state.

I would suggest attaching a Chipscope and looking at your key signals in the FPGA when it's not happy. My guess is that there is a clock not running somewhere. Are you using a DCM or PLL? What is your clock source?

If you read the Xilinx Spartan-6 configuration guide, there is a running CRC that is performed on the input bitstream that is validated at the end of the programming stream. If the CRC's do not match, the FPGA will not transition to the "done" state (the LED will remain off, and the INIT pin will drive low indicating a CRC error).

A good test might be to program your part using the JTAG POD repeatedly and see if the behavior changes. (does it work every time or do you get the same failure modes? If you see the failure modes, then it's likely not a loading issue).

So answers:

1. Sorry, nothing further than the ideas in the post you mentioned.
2. I would first get a chipscope and try to look at what the part is doing when it claims a successful load but is not driving the UPP ports. Are you crossing any clock domains? Etc. Also, are you sure that the UPP pinmux on the OMAP-L138 are set so that you do not get pin-mux contention? E.G., that the pins aren't set to LCD or RMII outputs, etc. u-Boot will configure the RMII pins if you configure it to run via RMII.
3. Removing the Base Module and the EMIF interface should not cause reliability issues, though you should ensure that the signals they were driving are appropriately set (interrupt lines, EMIFA bus is tristates, etc.).

-Mike

Hi Mike,

Thanks for your response and troubleshooting suggestions.

To answer your questions:

Are you using a DCM or PLL? What is your clock source?
I'm using a DCM as the clock source. Its source is the 100MHz EMIFA clock and its output is a 50MHz clock.

A good test might be to program your part using the JTAG POD repeatedly and see if the behavior changes. (does it work every time or do you get the same failure modes?
I did not notice the issue until I moved to programming the FPGA in u-boot. I will try using the JTAG POD to see if the issues is still there.

Are you crossing any clock domains?
That, I don't know. I'll have to investigate. What do you think the issue would be if crossing clock domains?

Also, are you sure that the UPP pinmux on the OMAP-L138 are set so that you do not get pin-mux contention?
Yes, that was one of the first issues we had to resolve.

Wade,

The EMIFA output clock can change if the OMAP-L138 CPU frequencies are modified (the EMIFA output clock is one of the SYSCLOCK divider outputs on PLL0).

Is it possible you are changing the CPU frequency or messing with the PLL? In this case, the DCM hooked to the clock may be breaking lock and will need to be forcibly reset before the clock will start up again.

We see this often with folks that program at u-Boot and then clock up the CPU from 300 MHz to 456 during linux runtime.

The base_module had provisions to detect breaking lock and issuing a reset to the DCM.

You might try using a plain old bufg (unless you need multipliers or the deskew logic) instead of the DCM and see if things improve.

Just an idea.

-Mike

Mike,

To my knowledge we're not changing the CPU frequency. That being said, one of the output messages during Linux boot is:

MityOMAPL138: setting max frequency to 456 MHz

But that doesn't necessarily mean the frequency was bumped to 456MHz, just that the max frequency limit is set to 456MHz, right?

If the base module handles the situation when the clock breaks lock, I should be able to transfer the logic from it into my code in order to handle the same circumstance. If this doesn't work perhaps an alternative is to have the DSP hard reset the DCM via a digital line connected directly to the DCM's reset line.

Thanks,
Wade

You might bring the DCM status lines (particularly the lock status) to a scope just to see if that is the core issue.

-Mike

Thanks Mike.

I'm troubleshooting using your suggestions. I'll let you know what I find.

Mike,

While troubleshooting the state of the lock status line I did discover there were instances of the clock not being locked, which I believe was the source of the problem we were seeing. I moved the clock monitoring code from your base module into our project and since then the apparent problem of the FPGA "not loading" has not occurred again (keeping fingers crossed).

Thank you for your help.

Wade