I’ve been running XEM3010-1500p boards for years with little trouble. For historical reasons we’re tied in to the 1.4 firmware. Recently we ran into something strange where the same FPGA code behaved differently depending on whether it is loaded into the PROM (with an *.mcs file) or into the FPGA directly (by installing or removing jumper J1). In the PROM mode we can’t access FPGA registers reliably through the okHostInterface, while in “direct” mode it all works fine.
It also seems to be related to changing the PLL parameters in eeprom. We mostly use sysclk2=20MHz. Increasing it to 25 MHz causes the host interface to break (although the rest of the FPGA works fine). OK, that’s probably bad timing in the FPGA. But the weird thing is, if we reprogram the PLL eeprom back down to 20 MHz, the interface remains broken (even after a complete power cycle). It’s almost as if programming the PLL eeprom when the FPGA has marginal timing is causing the non-PLL (i.e., firmware) portions of the microcontroller prom to become corrupt. Reflashing the whole firmware (including PLL, serial number, etc.) brings the board back to normal operation. And, this is not unique to a single board. We’ve tried it with multiple boards.
There may be multiple problems here, but the single strangest thing is that with J1 installed the FPGA works, while with J1 removed the host interface provides corrupt data.
Anybody seen anything even remotely similar?? Is there a way to verify the microcontroller eeprom firmware contents against the firmware package on the PC?