Honored Contributor
Honored ContributorYou might have been getting lucky with the "working" solution. It might be that it just so happens that the decoding logic worked in your favor and it worked previously. I have never seen Qsys let you have a 0 byte address span before so I have no idea what the fabric is going to do in that case. Are those two cores exposing address lines? I'm familar with the Qsys address decoder implementation and if that span of 0 is being used to generate the decoder logic then I don't think it'll decode properly... in short I'm surprised it ever worked for you.
I'm not sure what has to be done on the software side in terms of API calls but for a bridge to be active these need to occur: 1) The bridge needs to recieve an active clock from the clock manager (and the FPGA clock as well for the other side to work) 2) The bridge needs to be mapped into the address space, by default neither H2F bridge is mapped 3) The bridge needs to be taken out of reset (and the FPGA side as well) If you were able to get transactions through the lightweight bridge then I expected the above to already be taken care of in software for the H2F bridge as well. I think any time you configure the FPGA from the HPS the steps above are taken care of as well. The base address you access is different for the H2F bridge which is located at physical address 0xC000_0000, the lightweight bridge you were accessing before is much higher up in the address space. Perhaps your accesses are still being sent to the lightweight bridge.
