Problem in the power on of a system bases in a FPGA + uc

Hello!

I am breaking my head with the start up of a system based in a SPARTAN3 FPGA and one PIC18F4520.

One reset push button is conected to the FPGA. when I push this RESET button, the FPGA is reset and the uC is also reset by the FPGA. Everything is working fine in the uC and in the FPGA. However in the power on of the system. Everything is also working fine, but the uC miss the reset command sent by the FPGA. this reset command is read ok when I press the reset button...

The communication between the FPGA and the uC is based in the signals: hand and shake and one data bus of 8 bits. I play with "hand" and "shake" to have a success communication...

I figure out that maybe I have to wait for the uC to be ready for receiving some command. Maybe I have to implement a delay in the FPGA of 3sec and after that send the command to the uC....

Any idea about how to solve the power-on system problem??

Thanks!!

It sounds like the FPGA issues the reset to the microprocessor before it's ready, although that doesn't REALLY sound right. I would think the processor would start up before the uP. Have you looked at signals with an oscilloscope?

I don't know what you mean by "hand" and "shake"-does this have anything to do with reset?

Regardless, why don't you just TRY putting a delay in the FPGA and see if that solves the problem?

Thank you very much for your answer.

I already implemented a delay of 1sec in the FPGA before sending the reset command to the uC and it did not solve the problem...

I measured the signals with the oscilloscope and the hand signal drived by the uC to the FPGA did not work properly in the power up of the system. Hoerver if I make a reset with the button conected to the FPGA, eberything works fine...

Could be a problem of the compiler?

barry said:

It sounds like the FPGA issues the reset to the microprocessor before it's ready, although that doesn't REALLY sound right. I would think the processor would start up before the uP. Have you looked at signals with an oscilloscope?

I don't know what you mean by "hand" and "shake"-does this have anything to do with reset?

Regardless, why don't you just TRY putting a delay in the FPGA and see if that solves the problem?

Click to expand...

z

What I understand so far:
- The FPGA is configuration is automatically loaded after power on
- there's no regular hardware reset to the FPGA besides internal power-on reset
- the FPGA is expected to reset the µC, but this reset is either not asserted or not at the right time

When is the FPGA clock started? How to you derive the internal reset, e.g. starting the said 1 sec delay? Are you sure that the internal reset is working correctly?

This is a fairly common issue. At a minimum the FPGA and uC need to know the other is ready to go. You add another requirement of the FPGA starting up the uC. Can you post a schematic showing the reset handshake signals between the FPGA and uC? Include details like any pullup resistors. Also, perhaps a timing diagram of what you think is happening or any scope trace of actual timing.

Thinking ahead, why not use the internal startup of the uC to reduce the problem to just the two parts knowing if the other is ready. This can be done with two signals with pull-up resistors which go low when the part is ready. Then, if the FPGA has a problem, the uC can startup independently and respond to the problem. Usually the FPGA will have an optional "Configuration Done" output for this purpose with no logic required. A port pin on the uC can be controlled in software to go the other way.

Hello again!!

Finally I solved the problem. I was measuring all the signal carefully and I had a problem with the shake signal drived by the FPGA. It was drived later than I belived...And the reason was the time which delays the FPGA to be ready after the start up. I thought that the FPGA also made the reset of the uC. But it was not in this way!!! The FPGA and the uC started up without sync. So the FPGA started up later than the uC and it drived the shake signal to the uc later.

To solve this problem I implement a delay of 5 sec in the uC before executing all its code. This is not the "cleanest" way, but it works. In the future I will route a signal from the FPGA to the MCLR of the uC to sync the start up ob both devices...Any other idea??

Thanks.

Analog Ground said:

This is a fairly common issue. At a minimum the FPGA and uC need to know the other is ready to go. You add another requirement of the FPGA starting up the uC. Can you post a schematic showing the reset handshake signals between the FPGA and uC? Include details like any pullup resistors. Also, perhaps a timing diagram of what you think is happening or any scope trace of actual timing.

Thinking ahead, why not use the internal startup of the uC to reduce the problem to just the two parts knowing if the other is ready. This can be done with two signals with pull-up resistors which go low when the part is ready. Then, if the FPGA has a problem, the uC can startup independently and respond to the problem. Usually the FPGA will have an optional "Configuration Done" output for this purpose with no logic required. A port pin on the uC can be controlled in software to go the other way.

Click to expand...

FPGA POR and configuration delays should be pretty predictable, usually they are in a few 100 ms range.

It's also simple to get a "config done" signal from FPGA.