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

More
22 May 2022 20:03 #243574 by muvideo
Hello,
did you commit any changes on your LiteX-CNC repo?
I'm not seeing anything new there.
What should I modify to make the firmware build?
Thanks

Please Log in or Create an account to join the conversation.

More
22 May 2022 20:55 #243576 by TOLP2
Sorry, the commit was pushed just now ...

Please Log in or Create an account to join the conversation.

More
22 May 2022 21:16 - 22 May 2022 21:47 #243577 by muvideo
Wonderful, thanks, I confirm now it's working.
If I understand correctly, now it is generating the verilog file but
is not starting the generation of svf binary file.
Is it possible to have the binary generated trough
yosys/nextpnr directly like for litex template files?
Thanks,
Fabio

Edit:
Set builder.build(run=True) in __main__.py line 33
Tried also to run builder scripts generated by Litex
but I'm getting this error:

...
Successfully finished Verilog frontend.

3.3. Executing HIERARCHY pass (managing design hierarchy).

3.4. Executing AST frontend in derive mode using pre-parsed AST for module `\colorlight_5a_75e'.
Generating RTLIL representation for module `\colorlight_5a_75e'.

3.4.1. Analyzing design hierarchy..
Top module:  \colorlight_5a_75e
ERROR: Module `\IDDR2' referenced in module `\colorlight_5a_75e' in cell `\IDDR2_4' is not part of the design.
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
...

 
Last edit: 22 May 2022 21:47 by muvideo.

Please Log in or Create an account to join the conversation.

More
23 May 2022 13:48 #243611 by TOLP2
Small mistake, hard to debug. It is solved and pushed to the repo.

On the main branch the Colorlight FPGA's did work. When modifying the code to support more types of boards I made a typo  in the typhe of Ethernet PHY used on the Colorlight cards (ECP5). As a result, the buffer of the etehrnet packages was written to the wrong addresses. I did test the complete toolchain now from creating the firmware until compiling it to a bit-file.

As for your request to automatically built the bit-file, I'll put it on the board for the next iteration. Will implement it as a command-line argument, as not all users will have the complete toolchain installed within their environment (the ECP5 toolchain is the exception).

 
The following user(s) said Thank You: Bari, besriworld

Please Log in or Create an account to join the conversation.

More
23 May 2022 13:53 #243612 by muvideo
Thanks you for debugging ad updating the repo so fast. The error message was not very helpful to understand was was going wrong.
This evening I'll try again and update you on the results. I Hope to be able to make some quick tests on a 5a75e and 5a75b both V8

Fabio
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
23 May 2022 22:01 #243642 by muvideo
Built the firmware, built the driver, was able to connect to the board and made a quick
survey of hal commands.
test_stepgen.hal once adapted to my path and names is working,
test_gpio_blink is making something strange and gives an error:
litexcnc: Exporting functions...
rtapi_app: caught signal 11 - dumping core
but I have to double check my configuration.
I have worked only on 5A75E, I made some mistake on the build of 5A75B and now it's
giving an error on fingerprint, I have to rebuilt it's bitfile.
Tomorrow more testing.
All is very encouraging, wonderful work!
The following user(s) said Thank You: besriworld, TOLP2

Please Log in or Create an account to join the conversation.

More
24 May 2022 18:36 #243717 by TOLP2
In the blink example I see a pattern which I don't recommend to use anymore:
loadrt litexcnc
loadrt litexcnc_eth config_file="/home/pi/5a-75e-hello-gpio.json"
loadrt threads name1=test-thread period1=50000000
addf test_PWM_GPIO.write test-thread
addf test_PWM_GPIO.read test-thread
loadrt siggen
addf siggen.0.update test-thread

The order of adding the function to the thread does matter. In above example, in each cycle:
  • any data available will be written to the FPGA;
  • available data is read from the FPGA;
  • then the siggen will produce a new value which should turn the LED on or off. This value will be written in the next cycle.
A much tighter loop would be:
  • read data available data from the FPGA (this includes the position of the encoders and stepgen);
  • do something with that data and re-calculate the new state of the CNC-machine;
  • write the new demanded state to the FPGA.
For the very simple example above, this would result in the following hal-file:
loadrt litexcnc
loadrt litexcnc_eth config_file="/home/pi/5a-75e-hello-gpio.json"
loadrt threads name1=test-thread period1=50000000
loadrt siggen
addf test_PWM_GPIO.read test-thread
addf siggen.0.update test-thread
addf test_PWM_GPIO.write test-thread
The following user(s) said Thank You: besriworld

Please Log in or Create an account to join the conversation.

More
24 May 2022 22:06 - 24 May 2022 22:07 #243725 by muvideo
Made some tests
Working ok:
Pwm (3 of them)
Gpio outs
Not working:
Gpio out on j4:6 (it's the 12th gpio out in the config)
Gpio in (no one, tested 12 of them on j5 and j6)
Stepgens: strange numbers from Speed feedback.
Tested both 5a75e and 5a75b, both V8, same results.
Now I dont have the config files handy, let me know if they will be useful, in that case I'll upload them.

Thanks
Fabio
Last edit: 24 May 2022 22:07 by muvideo.
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
25 May 2022 09:03 - 25 May 2022 11:12 #243766 by TOLP2
Fabio, many many thanks for testing the firmware. Good to hear PWM and GPIO out are working. Those are also the ones which I could test, because I didn't desolder the buffers yet.

It is yet strange that the GPIO out on j4:6 is not working. To verify this is a problem of the driver or firmware, could you please test by swapping the first and the last GPIO (so putting j4:6 as the first pin). When j4:6 is still not working in that case, it is possible this pin has a special function not known to me. An bug in FPGA pins has been found earlier and could be an explanation for this behavior.

With regard to the GPIO in, this I didn't test myself yet. The FPGA does not have any pull-ups active in the firmware (don't know whether this is possible nor how to activate them if they are present). Also, if you are using any modified buffer, those don't have pull-ups either. Can you confirm you are actively driving the pins with HIGH and LOW signals and not by connecting the pin to the ground? Last question: can you share your method how you modified your buffers to accept inputs (the existing buffers only allow output, if they are not replaced or removed the board cannot accept inputs).
Edit: I see now that this is possibly due to an error with how the register is designed. Should have used a MultiReg . I will change this as well this evening to the correct register. 

Regarding the velocity feedback of the stepgens: I did only test the position of the steppers, with good correlation between commanded position and position feedback. Tonight, I will create a time-series which also includes speeds (both theoretical and feedback values from the driver) and see whether this an arithmetic mistake in the procedure. Thanks for the bug-report.

For testing the encoders:
  • first we have to verify that GPIO in is working correctly;
  • at this moment the data is transferred (counts), but this is not converted to position yet. The original ENCODER-component of LinuxCNC states in the man-pages that it handles overflow condition - it does NOT. In the firmware I'm working on accepting overflow conditions by making the registers 64-bit and repotrting the 32 LSB as counts. The position will be based on the 64-bit value though. This is the same approach as with the stepgens, which adds to consistency within the project.
  • I will add two extra options to the encoder: min_value and max_value (both in counts). When defined, it will clip the count-register to the specific bounds. This is easy for creating some rotary buttons for controlling the speed/feed override with some cheap encoders. 

I will give an update when the two latter points are ready!
 
Last edit: 25 May 2022 11:12 by TOLP2.

Please Log in or Create an account to join the conversation.

More
25 May 2022 12:30 #243788 by muvideo
About J4:6 and gpio inputs (and my crude implemetation of encoders) I tested 5a75b hardware on my own version of romanetz firmware, I worked on It sime time ago.
This evening I'll provide more info on my test enviroment and board mods to help you understanding what Is going on.
I'll try to make some more tests.
I was unable to use stepgens, maybe I'm not understanding their correct setup.

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.189 seconds
Powered by Kunena Forum