Unable to write to FPGA via EPI, but can read just fine

Hello Jeff,

I have seen other forum posts where an external FPGA access over EPI GP Mode works for both read and write and I can assure you that there is no way that a write to the external memory mapped device can cause a Reset to the device resulting in a re boot.

Did you check for any short on the board which may cause the Write signal from EPI to be connected to reset. Also please query the RESC register in SYSCTL to see what is the cause of reset.

Regards
Amit

Jeff McDevitt said:

I then updated the FPGA to support a read/write register at address 0. When I try to write data to the FPGA the processor reboots

We note that you can, "Still read good data from all other addresses."   And this (after) you've, "updated the FPGA to support a R/W register @ adr. 0."   Pardon - but is that (really) the case - and across all 16 addresses?   Sometimes - when we update our FPGAs - things do not go (entirely) as expected.

Assuming that you - indeed - continue to read good data - I've these suggestions:

• temporarily "break" the pcb trace between MCU & FPGA's write lines
• after that - generate that same (past) failing MCU write - does anything change?
• should opening the write connection eliminate the issue it appears worthwhile to apply a, "Dummy write pulse to the FPGA - either from a commonly grounded (and level set) function generator - or the MCU's GPIO.   Be sure to "match" the pulse width & voltage levels of the (real) write pulse - as best as you can

Method described here attempts to "isolate" the problem's cause - to MCU or the FPGA.

Of course you've produced more than one custom board.    What results when you test the other boards?

Have you measured the resistance of this "write line" both to ground and to VCC?   Is your 3V3 regulator suitable & adequate to task?   Depending upon your FPGA - that write operation may draw sufficient, extra current to trigger your (unwanted) MCU reset...   In one past case - client brought that common Write line to a board header - and incorrectly terminated it - which caused a current spike - yet not as serious as you report...

Amit and cb1,

Thanks for taking the time to reply and offer suggestions.

I did try it on a second board and saw the same results. After further investigation, I discovered that the FPGA  data bus connected to the EPI was not tri-stating during non-read times, and thus the Tiva part and the FPGA were both trying to drive the data bus at the same time. Oops. After fixing that the micro no longer reboots and the write pulse looks good. I am still unable to push data from the EPI into the FPGA, so I still have some work to do.

Thanks again,

Jeff

Hello Jeff

Could there have been some damage to the IO's output driver due to bus contention?

Regards
Amit

Hi Amit & Jeff,

Recall too - that such (unwanted) bus contention is a Two-Way Street - you may have damaged the MCU, the FPGA - and if (especially) unlucky - both!

I'd review - w/even extra care - that "update" of the FPGA.   If done fast/furiously - such is always "prime suspect."   (not to ask - How I know...)

Jeff McDevitt said:

As it turns out, my VHDL skills are a little rusty.

Whose are not?    Glad that you're now, "On the Air."