SSerial hardware implementation?
18 Jul 2019 00:15 #139747
by blazini36
Replied by blazini36 on topic SSerial hardware implementation?
I got ya, so I only need one instance in the pinfile....
I rebuilt the firmware with the new pinfile and still nothing. I'm just starting MK and looking at halshow to see it pick up "hm2_5i25.0.8i20......." pins as my 7i76e does. Is there any non HW dependant ways to see that SS is functioning in the FPGA? If it's a hardware issue I'll find it but if it's just not working in the MK build environment I'm using then I'm just gonna have to wait cuz I'm lost when it comes to programming.
BTW how's that 7C80 coming along? The RPI4 oughtta be a pretty serious contender for machine control by itself with something like that.
I rebuilt the firmware with the new pinfile and still nothing. I'm just starting MK and looking at halshow to see it pick up "hm2_5i25.0.8i20......." pins as my 7i76e does. Is there any non HW dependant ways to see that SS is functioning in the FPGA? If it's a hardware issue I'll find it but if it's just not working in the MK build environment I'm using then I'm just gonna have to wait cuz I'm lost when it comes to programming.
BTW how's that 7C80 coming along? The RPI4 oughtta be a pretty serious contender for machine control by itself with something like that.
Please Log in or Create an account to join the conversation.
18 Jul 2019 02:00 #139753
by blazini36
Replied by blazini36 on topic SSerial hardware implementation?
Just another thought.....
What's the most basic (cheapest lol) SS slave I can pick up? Bastardizing my mill is getting somewhat annoying, if I can just sit something on the bench for testing and provide logic power over RJ45 I'd be in better shape.
What's the most basic (cheapest lol) SS slave I can pick up? Bastardizing my mill is getting somewhat annoying, if I can just sit something on the bench for testing and provide logic power over RJ45 I'd be in better shape.
Please Log in or Create an account to join the conversation.
18 Jul 2019 03:11 - 18 Jul 2019 03:14 #139757
by PCW
Replied by PCW on topic SSerial hardware implementation?
If the driver prints out the sserial firmware version, that means the internal CPU is running
and responding to host data requests
I still suspect a wiring error as the most like cause of non-detection of SSerial remotes,
but another possibility is an incorrect CLKMED value in the firmware source
(The baud rate calculations that the SSerial processor does depend on this constant
matching the actual CLKMED clock rate)
The 7C80 hardware is fine but it still needs some driver support for its input module
(inMux)
I think the cheapest SSerial remote we make is the 7I73 but those are currently out of stock and
may be a couple weeks before we get our new build back from assembly
The next cheapest is the 7I90HD (in SSerial remote mode)
and responding to host data requests
I still suspect a wiring error as the most like cause of non-detection of SSerial remotes,
but another possibility is an incorrect CLKMED value in the firmware source
(The baud rate calculations that the SSerial processor does depend on this constant
matching the actual CLKMED clock rate)
The 7C80 hardware is fine but it still needs some driver support for its input module
(inMux)
I think the cheapest SSerial remote we make is the 7I73 but those are currently out of stock and
may be a couple weeks before we get our new build back from assembly
The next cheapest is the 7I90HD (in SSerial remote mode)
Last edit: 18 Jul 2019 03:14 by PCW.
Please Log in or Create an account to join the conversation.
18 Jul 2019 05:05 #139761
by blazini36
Replied by blazini36 on topic SSerial hardware implementation?
Not sure if this is the same thing but this is built with a separate parameter file which is just a rename job on my end. My pinfile specifies "ClockLowTag" for the SS module. Is that supposed to be "ClockMedTag"? Assuming the actual clockrate is passed from this file, the firmware has to be built with this file with the same naming convention.
I can't get a standard terminal print out of MK where you watch HM2 instantiate the hardware, I see the SS version on my LCNC machines like you said.
I can't get a standard terminal print out of MK where you watch HM2 instantiate the hardware, I see the SS version on my LCNC machines like you said.
package boardtype;
// DE0-Nano Dev kit and I/O adaptors specific info
// {STRAIGHT=0,DB25=1} BoardAdaptor;
parameter BoardAdaptor = 0;
parameter ClockHigh = 200000000; // 200 MHz
parameter ClockMed = 100000000; // 100 MHz
parameter ClockLow = 50000000; // 50 MHz
// parameter BoardNameLow = 32'h41524554; // "TERA"
// parameter BoardNameHigh = 32'h4E304544; // "DE0N"
parameter BoardNameLow = 32'h4153454D; // "MESA"
parameter BoardNameHigh = 32'h35324935; // "5I25"
parameter FPGASize = 9; // Reported as 32-bit value in IDROM.vhd (9 matches Mesanet value for 5i25)
// FIXME: Figure out Mesanet encoding and put something sensible here
parameter FPGAPins = 144; // Total Number of available I/O pins for Hostmot2 use Reported as 32-bit value in IDROM.vhd
// Proposal: On DE0 NANO board Limit to total count of gpios + arduinoconnectors + ltc + adc I/Os
// Maximum of 144 pindesc entries currently hard-coded in IDROM.vhd
parameter IOPorts = 3; // Number of external ports (DE0-Nano_DB25 can have 2 on each 40-pin expansion header)
parameter IOWidth = 72; // Number of total I/O pins = IOPorts * PortWidth
parameter PortWidth = 24; // Number of I/O pins per port: 17 per DB25
parameter LIOWidth = 0; // Number of local I/Os (used for on-board serial-port on Mesanet cards)
parameter LEDCount = 0; // Number of LEDs
parameter SepClocks = "true"; // Deprecated
parameter OneWS = "true"; // Deprecated
parameter BusWidth = 32;
parameter AddrWidth = 16;
parameter GPIOWidth = 36;
parameter NumGPIO = 2;
parameter MuxGPIOIOWidth = IOWidth/NumGPIO;
parameter MuxLedWidth = LEDCount/NumGPIO;
parameter ADC = "DE0-Nano-SoC";
parameter Capsense = 1;
parameter NumSense = 4;
endpackage //_HeaderIncluded
Please Log in or Create an account to join the conversation.
27 Jul 2019 00:09 #140702
by blazini36
Replied by blazini36 on topic SSerial hardware implementation?
So it appears that SS does do some sort of initiation on startup. I can get it to dump the startup to /var/linuxcnc.log and verify it prints "sserial version 0". I was wondering if sserial being from too old a version or missing sserialremote.vhd's could be the problem as these versions are older and those .vhd's are missing.
I have scoped and serial probed the transmit line on startup and can verify the Tx pin is sending some message. It's probably about 16 or so 7.75us pulses which I suppose suggests it's at a baud rate of 115200 but I get more substantial (i guess) serial messages at 230400.
Also I was wondering what "MuxedQCount" is used for, looks like it's used for an encoder like Qcount. Is that where the FPGA would accept differential signals directly rather than using an external differential receiver?
I have scoped and serial probed the transmit line on startup and can verify the Tx pin is sending some message. It's probably about 16 or so 7.75us pulses which I suppose suggests it's at a baud rate of 115200 but I get more substantial (i guess) serial messages at 230400.
Also I was wondering what "MuxedQCount" is used for, looks like it's used for an encoder like Qcount. Is that where the FPGA would accept differential signals directly rather than using an external differential receiver?
Please Log in or Create an account to join the conversation.
27 Jul 2019 00:20 - 27 Jul 2019 00:23 #140705
by PCW
Replied by PCW on topic SSerial hardware implementation?
The fact that it reads 0 as a version number means there is likely something wrong with the firmware source.
That is, the driver cannot communicate with the embedded CPU that manages he communications.
There never was a released version 0. I would expect version 43 if the source is less than 5
or so years old.
The initial baud rate should be 2.5 MBaud (400 ns per bit) I suspect something wrong with the clock
generation (the actual hardware clock does not match the CLKMED constant)
That is, the driver cannot communicate with the embedded CPU that manages he communications.
There never was a released version 0. I would expect version 43 if the source is less than 5
or so years old.
The initial baud rate should be 2.5 MBaud (400 ns per bit) I suspect something wrong with the clock
generation (the actual hardware clock does not match the CLKMED constant)
Last edit: 27 Jul 2019 00:23 by PCW.
Please Log in or Create an account to join the conversation.
27 Jul 2019 03:51 #140713
by blazini36
Replied by blazini36 on topic SSerial hardware implementation?
Just so it's clear to me, the pinfile specifying "version 0" and "ClockTagLow" has nothing to do with the actual printed version and the CLKMED constant you mentioned right? This is pretty much how all pinfile examples I've come across are setup.
Probably silly questions but programming is not my thing. Just wanna make sure I didn't set it up wrong before I write it off as something that's out of my control.
Probably silly questions but programming is not my thing. Just wanna make sure I didn't set it up wrong before I write it off as something that's out of my control.
Please Log in or Create an account to join the conversation.
27 Jul 2019 04:43 #140715
by PCW
Replied by PCW on topic SSerial hardware implementation?
The version numbers in the pinout file are hardware versions of the individual modules.
The sserial version that the driver reads out is the software version (of the code that runs on the sserial interface CPU) This should be 43 decimal, reading 0 probably means that the CPU is not responding or some other bitfile /firmware issue
The sserial version that the driver reads out is the software version (of the code that runs on the sserial interface CPU) This should be 43 decimal, reading 0 probably means that the CPU is not responding or some other bitfile /firmware issue
Please Log in or Create an account to join the conversation.
18 Aug 2019 23:52 #142465
by blazini36
Replied by blazini36 on topic SSerial hardware implementation?
I'm having a weird issue now that I can't quite track down but it has to be something in the firmware that is built from hm2.
I use 6 ABZ encoders, 6 stepgens, 34 GPIO and 1 SS that is disabled. Not sure what's up with SS yet but it may or may not be linked to the issue I'm having with 2 of my stepgens, the SS pins I was using are consecutive to the 2 stepgens that are not working right.
Took me a bit to realize the issue since It's not wired upto a machine using all of the I/O, I wound up building a test GUI. I found that 2 of the 6 stepgens don't output anything electrically, but hm2 thinks they are working. They instantiate, can be controlled, and the hal pins show feedback but verifying with the scope directly on the dev board's GPIO there is no switching on 3 of the 4 pins used for the 2 stepgens, only the 5th stepgen's direction pin works, neither work for the 6th. I've checked my daughtercard and verified that the interface circuit works fine with one of the working stepgen GPIO connected to those channels. First thought was that the dev board had damaged GPIO pins (I did do alot of hardware testing with this board) I picked up another one and I have the same issue fresh out of the box with the same firmware/software setup
This could be something with MK's build environment or something but I just wanted to see if there were some other parameter in hm2 that might dictate the amount of pins or pintypes in use. or maybe something else I missed.
I use 6 ABZ encoders, 6 stepgens, 34 GPIO and 1 SS that is disabled. Not sure what's up with SS yet but it may or may not be linked to the issue I'm having with 2 of my stepgens, the SS pins I was using are consecutive to the 2 stepgens that are not working right.
Took me a bit to realize the issue since It's not wired upto a machine using all of the I/O, I wound up building a test GUI. I found that 2 of the 6 stepgens don't output anything electrically, but hm2 thinks they are working. They instantiate, can be controlled, and the hal pins show feedback but verifying with the scope directly on the dev board's GPIO there is no switching on 3 of the 4 pins used for the 2 stepgens, only the 5th stepgen's direction pin works, neither work for the 6th. I've checked my daughtercard and verified that the interface circuit works fine with one of the working stepgen GPIO connected to those channels. First thought was that the dev board had damaged GPIO pins (I did do alot of hardware testing with this board) I picked up another one and I have the same issue fresh out of the box with the same firmware/software setup
This could be something with MK's build environment or something but I just wanted to see if there were some other parameter in hm2 that might dictate the amount of pins or pintypes in use. or maybe something else I missed.
Attachments:
Please Log in or Create an account to join the conversation.
19 Aug 2019 02:15 #142468
by PCW
Replied by PCW on topic SSerial hardware implementation?
.ucf file issues maybe?
Please Log in or Create an account to join the conversation.
Time to create page: 0.083 seconds