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

While E-stop active i see changed data on BOARD.stepgen.XX.position-feedback pin. After succsessfuly start linuxcnc BOARD.stepgen.XX.position-feedback pins not changed on all axes (have static numbers)

After some frustrating nights I have found the solution why it didn't work in LinuxCNC with the stepgen. Please find the complete file attached to this post. 

Most important part of the changes are in bold:
When the file is generated with stepconf the line defining the max velocity is not generated. Normally, the stepgen of LinuxCNC uses this value, but we cut this component out of the hal-file. So therefore we have to let the FPGA know (or better: the driver of the FPGA) what the limit of the machine is. When this parameter is not set the maxvel is 0 units/second. With other words: the machine won't move in this case.

Other change is that we use the position_prediction as position feedback for the joint. This is the speed the machine will be at when the next command is going to be executed. This gives a nice smooth behavior.

Dear Peter.
Please attach your .json file for this config. And .bit file if your board is a v8.0

Please find the JSON and the .svb-file for a 5A-75E rev 8.0 board in the attached .zip-file. Once flashed, the svb-file will work, however it is not persistent in the NAND-flash of the FPGA. Flashin a svb-file can be done using OpenOCD:
I use a Rapsberry Pi, but with modified pin-out, so I can use a flat-cable I had just laying around.

.
 

Dear Peter.
I try many times and many tools, but problem exist anyway.
And i see in Verilog file generated by Litex, THIS:

---

module colorlight_5a_75e (
        input  wire clk25,
        input  wire user_btn_n0,
        output wire sdram_clock,
        output wire eth_clocks_tx,
        input  wire eth_clocks_rx,
        output wire eth_rst_n,
        input  wire eth_mdio,
        output wire eth_mdc,
        input  wire eth_rx_ctl,
        input  wire [3:0] eth_rx_data,
        output wire eth_tx_ctl,
        output wire [3:0] eth_tx_data,
        input  wire gpio_in0,
        output wire gpio_out0,
        output wire gpio_out1,
        output reg  pwm0,
        input  wire stepgen0_step,
        output reg  stepgen0_dir
);

---

And my question: HOW step may be INPUT?

I try to search error in code and found

---

# Link step and dir
self.comb += [
pads.dir.eq(self.step),
pads.dir.eq(self.dir),
]

---

Change to pads.step.eq(self.step), and in Verilog file i see correct declaration.
But this not resolve main problem

Thanks for spotting that error! I pushed it right to the repo, together with some small updates on the stepgen (mostly debugging).

The main issue you described is:
- the BOARD.stepgen.XX.position-feedback gives erratic readings when machine is in E-stop mode;
- the BOARD.stepgen.XX.position-feedback is static when E-stop is not active;
- do you still get following errors (I assume you do).

It is strange, as with my test setup I, as added a few posts above, I cannot replicate this behavior. Did you change your HAL-file with the changes above, because I see in your original HAL-files you tied into the veloctiy command without setting the parameter position_mode to False. The code in your HAL-file should look like this:
When you are setting the velocity-cmd pin when in position mode, there will be no data be send to the card (because the commanded position remains 0). Maybe we should throw an warning when this happens?

At this moment I'm on holiday and I don't brought my test-bed with me. Will be back in the beginning of August. Hope that above will solve (part of) your problem.

Dear Peter.
Lately I've been working with your hal/ini files that you posted.
And while the error persists, even with the fix I found.

- the BOARD.stepgen.XX.position-feedback gives erratic readings when machine is in E-stop and not E-Stop mode;

Perhaps this is a board bug, but in the main function (LED control) everything works fine. I'm buying another 75e and waiting to receive.

P.S.
gpio_in also gives erratic readings.
I resoldered some buffers and attached buttons/switches to them. And reading the state of these buttons also gives an error and does not reflect the actual state of the port.
P.P.S
I have two boards for experiment at the moment: ColorLight 5a-75b v8.0 and ColorLight 5a-75e v8.0,
and on both I have the same firmware behavior

Could you please post the following:
- your json file
- hal-file(s)
- the source of the driver you have compiled. Please make sure you have done the (modified) halcompile on the files.

Based on the erratic readings I have a feeling that either the wrong address is read, the driver might have a different version then which I'm testing (causing mis-alignment of the data) on or as the last possibility a broken board.

Dear Peter.
All files in attached archive. 

Hello!
I have the same problems as svb:
- input pin don`t work right
- stepgen auto starting with random value

Output pin and PWM work fine,

card Colorlight 5a-75b V8.0