build fails with ValueError: Cannot extract CSR name from code, need to specify after.... python update?
#122
-
|
I'm not sure what really happened to have this error start, I hadn't touched my config in months, and checked against old, known to work configs and get this error every time. It happens in my old build environment and in freshly created ones, the only thing I can think of having changed would be my python version being updated. I'm running Arch Linux, so the Trying to dig in myself but progress is slow going, if anyone know migen/litex better any hints would be appreciated! Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 14 comments 16 replies
-
|
Thank you for using LitexCNC. Over the past few months there have been updates in LitexCNC, so maybe there has been something changed. I would love to help you further on this subject. Could you please:
|
Beta Was this translation helpful? Give feedback.
-
|
I just manually performed what the _install_litex method did, wget'ing my main config, other simpler configs had similar results. |
Beta Was this translation helpful? Give feedback.
-
|
I also run |
Beta Was this translation helpful? Give feedback.
-
|
You might consider upgrading
You can install this version with: pip install git+https://github.com/Peter-van-Tol/LiteX-CNC@119-feature-request-revamp-watchdogAfter installing the new version you need to update the driver and the toolchain: litexcnc install_toolchain
litexcnc install_driver
To use the new version of {
"name": "lilred",
"board_name": "lilred",
"board_type": "5A-75E v6.0",
"clock_frequency": 40000000,
"ethphy": {
"tx_delay": 0
},
"etherbone": {
"ip_address": "172.27.0.20",
"mac_address": "0x10e2d5000000"
},
"connection": {
"connection_type": "etherbone",
"tx_delay": 0,
"ip_address": "172.27.0.20",
"mac_address": "0x10e2d5000000"
},
"watchdog": {
"functions": [
{
"function_type": "heartbeat",
"pin": "user_led:1",
"invert_output": true,
"waveform": "heartbeat",
"speed": 0.857
},
{
"function_type": "enable",
"pin": "j2:0",
"invert_output": false,
}
],
},
"modules": [
{
"module_type": "gpio",
"instances": [
{"direction": "in", "pin":"j2:1"},
{"direction": "in", "pin":"j2:5"},
{"direction": "out","pin": "j16:1"},
{"direction": "out","pin": "j16:5"}
]
}, {
"module_type": "pwm",
"instances": [
{
"pins": {
"output_type": "single",
"pwm": "j15:1"
}
}
]
}, {
"module_type": "encoder",
"instances": [
{"pin_A":"j3:0", "pin_B":"j3:1"},
{"pin_A":"j3:2", "pin_B":"j3:4"},
{"pin_A":"j3:5", "pin_B":"j3:6"}
]
}, {
"module_type": "stepgen",
"instances": [
{
"pins" : {
"stepgen_type": "step_dir",
"step_pin": "j7:0",
"dir_pin": "j7:1"
},
"soft_stop": true
}, {
"pins" : {
"stepgen_type": "step_dir",
"step_pin": "j8:0",
"dir_pin": "j8:1"
},
"soft_stop": true
}, {
"pins" : {
"stepgen_type": "step_dir",
"step_pin": "j9:0",
"dir_pin": "j9:1"
},
"soft_stop": true
}
]
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
Yeah as part of my debugging I tried to get to bleeding edge on everything but as you said, it's still giving the CSR error.. |
Beta Was this translation helpful? Give feedback.
-
|
For bleeding edge, you can now use the just released version 1.3.0 from PYPi. Comparing to the version you are using now, there are some more issues resolved:
|
Beta Was this translation helpful? Give feedback.
-
|
It seems like this new release isn't creating an executable in the venv bin/ directory |
Beta Was this translation helpful? Give feedback.
-
|
You can still use it (after activating the environment) with: python - m litexcncI will try to replicate and create an issue. Edit: On Windows the installer still installs the scripts, however on Linux is does not. Very strange indeed. I'll release a new version, which has an updated |
Beta Was this translation helpful? Give feedback.
-
|
Just released version 1.3.1 to solve this problem. Thank you for bringing attention to this issue. Edit For example: venv ~/venvs/litexcnc_test/
source ~/venvs/litexcnc_test/
pip install litexcncwill result in the script In my case, Linux was still looking in the wrong folder. When I run Most important: the script is generated again! |
Beta Was this translation helpful? Give feedback.
-
|
also, good news, the updated config successfully builds on my Debian based laptop, so that will allow me to move forward at least, and give a point of comparison in debugging what going on with my desktop. I'll also be looking closely at if this is a LiteX, or specifically LiteX-CNC issue. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this heads up! I've found the source of the error. One of the dependencies of Litex does not support Python 3.13 yet. Most likely your Debian setup has Python 3.12 or less. Until Migen has been patched, we cannot support Python 3.13. On your Arch Linux system, create a |
Beta Was this translation helpful? Give feedback.
-
|
Very cool! Last night I setup a build container with python 3.12 and it's got me up and running. Hoping to get my mini mill (lil' red!) up and running in next few days. |
Beta Was this translation helpful? Give feedback.
-
|
I suspected Python version might was the major difference between my two systems. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! The problem is with the encoder module. Removing it from the configuration everything works. The driver gives an error with it.
` |
Beta Was this translation helpful? Give feedback.
-
|
Can you please share your config which gives this error? I've the feeling that with merging all requests something went wrong with the data-size of the stepgen configuration. The module id
Tonight I have time to create a fix... |
Beta Was this translation helpful? Give feedback.
-
|
I will attach the configuration file, there is quite a large volume in modules. This configuration compiles very well in version 1.2.4 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the config! Because I've not a 5A-75E laying around at this moment, I've re-written your config so it fits on my 5A-75B. I only selected the stepgen and the encoder to see how it goes. I've found an error in the driver of the The configuration for version 1.3.1 (and the upcoming bugfix version 1.3.2) has a slightly modified definition for the watchdog. I see you use an enable pin, so I added that to your config. Also, as you're using a 5A-75E which has a built-in user LED, I've added a heartbeat. See you're updated configuration below. |
Beta Was this translation helpful? Give feedback.
-
|
I've just released version 1.3.2 which resolves your issue. You have to re-compile your firmware and re-install the drivers. The release has been tested on your config and all stepgen and encoders are showing. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for your great work and prompt fix. Yes, I have 5 engines, I use XYYZA. |
Beta Was this translation helpful? Give feedback.
-
|
LinuxCNC stopped working. I deleted almost everything from ini and hal files. |
Beta Was this translation helpful? Give feedback.
-
|
When viewed in halrun it shows a strange module. |
Beta Was this translation helpful? Give feedback.
-
I think a debug statement is still active. Nothing to worry about; in the next release I will turn this one off.
Can you share your HAL-files. I think there is a configuration error in the used pin-names. In previous version of LiteX-CNC there was an inconsistent use of On my part, I want to check whether the generation of aliases is still working accordingly. |
Beta Was this translation helpful? Give feedback.
-
|
To run LinuxCNC, I deleted everything from the hal file except for running the driver and the watchdog timer copied from the example. Unfortunately, something went wrong during the next firmware update). Apparently, it was because I was doing this on a breadboard, a failure occurred and the FPGA burned out. I think that since the 74CH245 has a different direction and the controller applied voltage to the output, a short circuit occurred. The resistors that are on the board did not save it, since they are 30 Ohm, which is 100 mA. |
Beta Was this translation helpful? Give feedback.
-
|
When you replace the buffer (see the HUB75HAt repository) younshpuld power them by 3.3 volt. The veesion recommended is 5 volt tolerant, but outputs 3.3 volt, which is safe. Are you located within EU? I could ship one to you if you want... |
Beta Was this translation helpful? Give feedback.
-
|
I took into account the change of signs. But now I will not be able to try it earlier than in a couple of weeks when I receive a new board. Now in the redesign of this board it is necessary to take into account the disconnection of the power supply of the buffer microcircuits at the time of firmware. |
Beta Was this translation helpful? Give feedback.
-
|
I was unable to check in the new firmware, but in version 1.2.4 there was the following problem. When either after closing the LinuxCNC program or after turning off the machine in the program at the output of the driver control pulses appeared. This is clearly visible on the oscilloscope. And the most interesting thing is that if you write something like net param1 => Name.stepgen.00.position-cmd and net param1 => Name.stepgen.01.position-cmd in hal, then the pulses were synchronous at both outputs. To solve this problem, I used additional outputs to control the "enable" stepper motor driver. |
Beta Was this translation helpful? Give feedback.
-
|
This problem has been resolved with the new watchdog. If you have the means to check it, please checkbit with the new version. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, my board burned out |
Beta Was this translation helpful? Give feedback.
-
|
See my other reply. I can send you a board if you are within the EU. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not in the EU. I should get the controller by January 25th and also have to remake it. |
Beta Was this translation helpful? Give feedback.
Thanks for this heads up!
I've found the source of the error. One of the dependencies of Litex does not support Python 3.13 yet. Most likely your Debian setup has Python 3.12 or less.
Until Migen has been patched, we cannot support Python 3.13. On your Arch Linux system, create a
venvwith a lower Python version and it will most likely work,