ColorCNC Colorlight 5A-75E/5A-75B as FPGA controller board

Back from a nice holiday and now solved the above problem. Implemented a start-up procedure:

• Check whether the data on the FPGA on address 0x0 is equal to 0x18052022. This indicates that we are talking to a FPGA which is configured for LitexCNC;
• Check the fingerprint of the config-file on the PC and as used for programming the FPGA. When these configurations are not equal, LinuxCNC will not proceed, as the pin-out might be changed. As fingerprint the CRC-checksum of the file is used. This is well-defined in both Python (for LiteX) and C (for the driver).
• Reset the FPGA, this will stop all movement on any stepgen present and resets the counters to their starting positions. Because the reset is very important, the reset-bit is first written and then read back from the card. Only when the value which is read back equals the reset-state, the driver set the reset-bit to 0 and the FPGA will go to the normal state.

Also started to work on the encoder and received finally the RV901T to try that one as well. Keep you all posted!

Such amazing progress!

I've been distracted with other projects but plan to pivot back to testing this soon. Excited to get tons more inputs on my machine and go from software stepgen to hardware

These all are the great news!
With RV901T, ISE 13.7 failed to build the firmware. (I've chosen this ancient version of ISE to be able also to build hostmot2 firmware).
And with the latest version of LiteX, for Colorlight 5A-75 v. 8.0 and liteeth in 32-bit mode, timing issues are not met.

@romanetz: if I understand you correctly you are trying to install the orginal MESA firmware on a re-purposed card such as the RV901T? Can you elaborate on the timing issues of the latest version of Litex, would that affect the LitexCNC project, or does it only affect the installation of the MESA firmware?

Update: Sending the wrong data to the card can lead to dangerous situations (worst case; uncommanded movement) or hard to debug problems. To solve this I already added checking the fingerprint of the configuration used for the card and driver; checking whether we talk to the same configuration. Now I also added firmware version in the header. The driver now checks whether the version is compatible with the firmware: when the communication protocol has changed (for example due to adding a new component), the version number is increased and the user is informed to update the firmware and/or driver (depending which one he upgraded first). 

No, my plan was just to compile colorcnc firmware for Xilinx platform. A lot of changes is needed to original firmware to implement Mesa on RV901T platform: at least, move here udp/ip stack, say as from Alex Forencich github: github.com/alexforencich/verilog-ethernet
Now about uncommanded motion. I consider that it's necessary to implement some kind of a state machine like in ethercat: IDLE-> (transition by command) PREOPerational<->SAFEtyOPerational (process data available, no control) <-> (forward transition by command, backward transition by timeout) OPerational
And all boards must follow such set of a predefined commands. Say like in left corner of the attachment.

Thanks for the poster, that is a nice one to keep in mind for further improvements.

At this moment there is a state machine in LitexCNC (not in the original colorcnc), however it is simpler then the EtherCAT one:

• IDLE: Watchdog is timed out, all inputs / outputs are in safe state and the stepgens are stopped;
• INIT: The master requests header information to verify the configuration of the card and firmware. The watchdog is still timed out and the outputs stay in safe state and stepgen stopped.
• RESET: The master sends the reset signal to the FPGA and verifies it has been correctly received. This ensures the stepgen counters are reset to a known state, preventing uncommanded moves when the HAL-cycle starts sending data. The watchdog is still timed out.
• ACTIVE: The master reads data from the FPGA, processes it (by using other components) and at the end of the cycle sends the commands back to the FPGA. The watchdog is being petted and after a pre-defined time-out (1,5 ms in the examples)
• WATCHDOG_BITTEN: When the watchdog times out the inputs and outputs go to safe state and the stepgens are stopped. Depending on the settings, the stepgens are stopped gently (with keeping acceleration limits in mind) or harsh (stop direct).

At this moment the state-machine goes from top to bottom when LinuxCNC or the HAL is first started. An improvement is still required on the transition between WATCHDOG_BITTEN and ACTIVE. At this moment as soon as the watchdog is petted again, the movements start again. Theoretically the machine did not loose steps, but I think it is better to stop the machine and enforce a RESET state.

So: safety is in the design of LitexCNC and I really do appreciate people actively seeking for safety!