#linuxcnc-devel Logs

Apr 02 2018

08:04 AM rene-dev: pcw_home pcw_mesa I think there is a problem with the crc flag check in the sserial driver.
08:06 AM rene-dev: if the fpga receives a packet with invalid crc, does it just set the crc error bit here? https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/sserial.c#L2258
08:14 AM rene-dev: I think this call needs to go outside the if. https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/sserial.c#L1783
08:14 AM rene-dev: or does a crc fail also trigger one of the other errors?
09:22 AM pcw_home: AFAICR it just sets the one CRC error bit on RX CRC error
09:26 AM rene-dev: then there is a bug in the driver...
09:28 AM pcw_home: I also think the channel most be stopped and restarted to clear the error
09:33 AM rene-dev: ah... remember that wired crc problem I had a while back, where the stmbl got packages with bad crc? it turned out to be a cable issue
09:34 AM rene-dev: and same the other way, the fpga got bad packages, but I think they never got reported
09:35 AM rene-dev: so I cant tell. but I send the position back as a float, a bitflip causes a big jump
09:36 AM rene-dev: and I got completley random following errors sometimes, this could be the cause
09:37 AM rene-dev: so it would be intetesting if the driver just ignores the crc error flag, and just uses the corrupted data...
09:42 AM pcw_home: that would not be good
09:46 AM rene-dev: looking at the code, that is how I think it behaves. I could add some code that sends corrupt packages once in a while to verify that.
09:46 AM rene-dev: because hm2_sserial_check_local_errors is only called in the if
09:48 AM rene-dev: do the registers get updated on crc fail?
09:48 AM pcw_home: I dont think so
09:49 AM pcw_home: but stale is as bad as corrupt in some cases
09:50 AM rene-dev: look here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/sserial.c#L1818
09:50 AM rene-dev: I dont know what that means, but in that case it still updates the pins
09:51 AM rene-dev: that would then set all pins to 0, or whatever was last in the registers...
09:51 AM rene-dev: ah, probably the last stuff from the tx :D
09:52 AM pcw_home: Yeah Im not really sure whether it uses the previous RX data
09:53 AM rene-dev: maybe it just needs a return after line 1819? can you trust the data in the registers if the condition in line 1818 is true?
09:53 AM pcw_home: not TX since there are separate TX and RX registers
09:55 AM pcw_home: yes, you will get a failed transfer on CRC error
09:56 AM pcw_home: but you should never use the data in that case (failed xfer)
09:56 AM rene-dev: ok, then in that case there is a bug, as increments the fault counter, but still updates the pins
09:56 AM rene-dev: so it probably just needs a return
05:30 PM stustev: cradek: Hi,
05:30 PM stustev: For the source code, please visit the page
05:30 PM stustev: https://github.com/emogenet/rs274ngc
05:30 PM stustev: I think you may compile those with normal 'gcc' and 'make'.
05:30 PM stustev: If not, please refer the contents of 'Makefile'.
05:30 PM stustev: Kazu
05:30 PM stustev: cradek: this was his answer today
05:31 PM stustev: cradek: I have the zip and a clone - will play with it tomorrow
07:18 PM pcw_mesa: Hmm I wonder if mesaflash works on the RSPI/SPI...
07:20 PM pcw_mesa: It would be a pain to have to go back to EPP to reprogram the cards
07:32 PM rene-dev: I see no reason why not?
07:33 PM rene-dev: are there many people using them?
07:33 PM rene-dev: I guess you could bitbang epp via the rasp gpios :D
07:45 PM Tom_L: this only affects spi right?
08:16 PM pcw_home: Yes only hm2_spi
08:19 PM pcw_home: and specifically TopGCSPIHostMot2 (GC for Global Clock)