If px .exe can see the 1-2-3 FPGA as Com3, then Propeller Tool SHOULD be able to see it as Com3.
PropellerTool does scan COM3... it just reports no hardware found there.... So the tool is seeing COM3 ok. I don't think this has anything to do with the P1V since I can't get OzPropDev's stuff to work either.
There is a jumper... marked "P8X32 PGM" set to the left position. I tried moving it to the right and had same results.
With PGM/RUN in PGM and the P8X32 jumper to the right, you should see the 1-2-3's on-board Prop. This of course, should respond like a real propeller.
I'm lost at this point. I was having FTDI driver issues like this on my Windows 7 laptop, and started installing and uninstalling the FTDI drivers with the FTDI utilities. The resulted in a ever deepening and frustrating rabbit hole of FTDI issues and the laptop finally turned into a REALLY NICE Fdora Linux laptop. I won't suggest anyone play with drivers after that experience.
Maybe Parallax will swap 1-2-3 boards with you? Brian's is working fine and mine is working fine with a number of tool talking to it. I don't know if we've heard from any other owners. Maybe you just got a bad board? I'm sure there are a few left in stock (25 by last count) to swap with!
The fact that it works with px.exe and not Propeller Tool still seems rather strange to me.
Sorry... I had the jumper to the right but the switch in RUN. You are correct PropTool does see it as a Propeller! AND!!! it loads RAM:) And my program is talking back to me over serial as it should.
- talk to the onboard Prop in PGM and the jumper to the right through px.exe - this uses the loader program running in on-board prop to load the FPGA image
- talk to the onboard Prop in PGM and the jumper to the left through Prop Tool - this allows you to load a Spin program to the onboard Prop (I would think this would be used very rarely - only when a new loader came from Chip.
Your FTDI can't talk to a P1V loaded into the FPGA when in RUN with the jumper to the LEFT - this should connect the FTDI RX/TX to the FPGA pins and your FPGA image should map those to P1V P30/P31 for normal Propeller serial I/O
Your FPGA is able to load into its memory an image that you downloaded to the 1-2-3 board with px.exe - we see this when you load my image and the active/inactive lights display properly.
So, what's broken??
Something to do with the jumper labeled "P8X32 PGM"? for almost all cases, it should be to the LEFT. You don't want to mess with the (proven working) program loaded into the onboard Propeller.
All it looks like that jumper does it pull ~RESn high so the onboard Prop can't reset. It looks like RX/XT from the USB are wired to both Prop and FPGA at that point.
I think I have it sorted correctly... To download .rbf to the FPGA: jumper on left, Switch to Prog.
To program the P1V move the jumper to the right (use RAM) for program, leave switch on Prog... (Load Ram only so as not to overwrite the loader sitting on the EEPROM.)
The only issue at this moment seems to be pin mapping. P8+ maps to red LED's
I don't see that P0-7 are mapped. If that is all the way it should be, I'm a happy clam.
If I do everything as above in terms of switch and jumper settings, I can load the .rbf
loop back test that ozpropdev sent me. I can load the spin file into RAM, but the serial terminal does NOT get the feedback and so that loop back...seems to fail. I haven't played with the above settings. I have run my own program, and if I indeed am using the P1V...as described above:)... duplex serial seems to work.
NO! The jumper only needs to be on the RIGHT if you are reprogramming the on-board REAL Propeller. For anything else, the jumper block needs to be on the left. I don't have the board with me - I can upload a picture tonight to we are talking about the same left and right.
The pin mappings you are seeing are the REAL Propeller. P8+ are hard wired to the FPGA data pins - they flash a lot when loading an image.Youcan;t get to those LEDs.
With the jumper on the LEFT, PGM is used when you run px.exe to send an FPGA image down to the 1-2-3 board. RUN is used when you are running your image on the FPGA - it attaches the FTDI RX/TX pins to the FPGA pins that are mapped in the case of the P1V to P30/P31 on the VIRTUAL Propeller.
I went back to square 1... even reloaded px.spin into the EEPROM. No love from my P123. But I'm going to give it a rest and then try it again.
mindrobots:
Maybe Parallax will swap 1-2-3 boards with you? Brian's is working fine and mine is working fine with a number of tool talking to it. I don't know if we've heard from any other owners. Maybe you just got a bad board? I'm sure there are a few left in stock (25 by last count) to swap with!
I could do that, but I have never had it happen before... and I deeply suspect my own ignorance at this point.
I think I will just order another board... and if it works and this one doesn't then we can swap it out.
I need extra boards anyway, because I have a contest to run AND it is always good to have two boards that both work:)
mindrobots:
The pin mappings you are seeing are the REAL Propeller. P8+ are hard wired to the FPGA data pins - they flash a lot when loading an image.Youcan;t get to those LEDs.
It was the entire row of red led's that lit up... I don't see anywhere in the schematic that they are hooked to the real Prop on the board?
I can see where the user-led's are in the schematic... and there are only 16. I don't see anything about dedicated led's... just wondered. Kind of cool though:)
Brian the .rbf loads without a hitch. When I try to run the spin file with PropellerTool
Compile Current->load ram... it doesn't find the Propeller.
I'm using Propeller Tool 1.3 Windows 8.1
I've attached a picture of the control panel reports... doesn't look like that is the problem.
I have also tried several different cables... all of them work with px... none of them allows Propeller Tool to see the P1V. I am using Prog & Run correctly. I do a power cycle between Prog and Run and in Propeller Tool removing and re-inserting the usb cable doesn't help.
Rich
There is no boot loader in the rbf file I posted, only a loop back test. (The .spin code included for reference).
So proptool will not recognize the fpga but any serial terminal prpgram should receive what was transmitted. We know your USB/FTDI side is ok as it talks to the real prop via px.exe ok.
So if you don't get any response from my loop back code I suspect a problem with the mux/demux circuit.
Sorry for any confusion.
Cheers
Brian
Glad to be awake... horrible dream about playing golf with Arnold Palmer... to get to the next hole, we had to shimmy down a cactus. I don't think it has anything to do with loop back tests:)
Thanks for the explanation... and I have mixed results to report.
Loop back seems to work just fine at 300 and 1200 baud... after that it gets more and more unreliable with increasing baud rates.
Which Win10 machine? I'm currently using an HP with an A8. But it clutters up my desktop... with all of these boards, power stations, and monitors. And of course, I can't kick it like I want to sometimes.
I'm having a problem talking to the FPGA once px.exe has loaded a binary image(.rbf). I think I'm the only one using windows 8.1. So it could be something related to that.
I have some (verilog)VGA code that looks like it should work ... but doesn't. I think it is the
way I'm driving the DAC, but it could be a hardware issue with the board... not likely. I posted a .rbf file for testing in the P123D VGA thread. If it works on another machine but not mine, then there is a component on my board that didn't sit down when it was told to... or which passed batch testing but which didn't make it to real life:)
Either way, I was planning to order a second board when Chip released the next binary... sounds extravagant... but considering my life it makes perfect sense:)
Either way, I was planning to order a second board when Chip released the next binary... sounds extravagant... but considering my life it makes perfect sense:)
I'm still tempted to order a 1-2-3 board but I need to get to a point where I could actually make use of it first. It is a BEAUTIFUL board!
It is a thoroughly professional board... if anyone else made it, they would charge 3X as much... honest to God.
People keep comparing it to low end entry level products... go look at the other end:)
And... what keeps hobbyists locked out is the way the entire business of FPGAs is structured... it isn't amateur friendly. Intellectual property sales are great for the engineering community, Universities and medium to large sized companies, but they are death to casual conversations and novices. There is an enormous, freely available stockpile of info out there that is almost completely unapproachable. You really should be an engineer to wade into it.
"let me show you how to use an FPGA... but once you have learned, you can't use anything unless you pay me."
Makes perfect sense to the intended audience... of which we are not part.
I think I'm the only one using windows 8.1. So it could be something related to that.
I don't think its a Win8.1 issue as I am running my 123 board on Win8.1 as well as a Win10 with same results.
I would however expect the loop back test to operate reliably way higher than 460800 baud. Pointing finger at Mux/Demux.
ok... I have a new Propeller123 fpga board, wiped my computer clean. Re-installed everything from scratch, Windows 8.1, Quartus 15, with upgrade to 15.02. Files from Chip, etc. etc.
The net result is that I am back to where I started. PX.exe hiccups occasionally but fairly reliably programs the P123 with a P1V from Jac's github... which I also downloaded fresh.
The resulting P1V image is clearly on the board, because when I switch the switch from prog to run... I get the proper LED indicators... one green for Cog0. But the P1V is not recognized by either the PropTool or PropellerIDE.
I cannot get the board to loop through using Ozpropdev's program... at any baud rate.
I have included the compiled .rbf. It could be something in my compile (although given the serial loopback failure, I doubt it:)
so... I could suppose that I have two boards with the same problem and you have a board that doesn't have that problem... or my AMD A8 based HP notebook handles serial in an odd way.
Just to re-re-iterate. PX.exe seems to load the .rbf image just fine, but PropTool can't find the P1V.
Two different P123 boards.
I'm running Windows 8.1. Ozpropdev has previously confirmed that 8.1 is not the issue. And the .rbf file is not the issue. I'm using the right driver... I think:)
The only other thing I can think of is that I'm running Windows Defender, with all the options...
is there a setting in Defender or somewhere else that can account for this?
Comments
PropellerTool does scan COM3... it just reports no hardware found there.... So the tool is seeing COM3 ok. I don't think this has anything to do with the P1V since I can't get OzPropDev's stuff to work either.
There is a jumper... marked "P8X32 PGM" set to the left position. I tried moving it to the right and had same results.
I'm lost at this point. I was having FTDI driver issues like this on my Windows 7 laptop, and started installing and uninstalling the FTDI drivers with the FTDI utilities. The resulted in a ever deepening and frustrating rabbit hole of FTDI issues and the laptop finally turned into a REALLY NICE Fdora Linux laptop. I won't suggest anyone play with drivers after that experience.
Maybe Parallax will swap 1-2-3 boards with you? Brian's is working fine and mine is working fine with a number of tool talking to it. I don't know if we've heard from any other owners. Maybe you just got a bad board? I'm sure there are a few left in stock (25 by last count) to swap with!
The fact that it works with px.exe and not Propeller Tool still seems rather strange to me.
Thanks
- talk to the onboard Prop in PGM and the jumper to the right through px.exe - this uses the loader program running in on-board prop to load the FPGA image
- talk to the onboard Prop in PGM and the jumper to the left through Prop Tool - this allows you to load a Spin program to the onboard Prop (I would think this would be used very rarely - only when a new loader came from Chip.
Your FTDI can't talk to a P1V loaded into the FPGA when in RUN with the jumper to the LEFT - this should connect the FTDI RX/TX to the FPGA pins and your FPGA image should map those to P1V P30/P31 for normal Propeller serial I/O
Your FPGA is able to load into its memory an image that you downloaded to the 1-2-3 board with px.exe - we see this when you load my image and the active/inactive lights display properly.
So, what's broken??
Something to do with the jumper labeled "P8X32 PGM"? for almost all cases, it should be to the LEFT. You don't want to mess with the (proven working) program loaded into the onboard Propeller.
All it looks like that jumper does it pull ~RESn high so the onboard Prop can't reset. It looks like RX/XT from the USB are wired to both Prop and FPGA at that point.
I've run out of suggestions, I think.
To program the P1V move the jumper to the right (use RAM) for program, leave switch on Prog... (Load Ram only so as not to overwrite the loader sitting on the EEPROM.)
The only issue at this moment seems to be pin mapping. P8+ maps to red LED's
I don't see that P0-7 are mapped. If that is all the way it should be, I'm a happy clam.
thanks again
Try more than 1 terminal...
If I do everything as above in terms of switch and jumper settings, I can load the .rbf
loop back test that ozpropdev sent me. I can load the spin file into RAM, but the serial terminal does NOT get the feedback and so that loop back...seems to fail. I haven't played with the above settings. I have run my own program, and if I indeed am using the P1V...as described above:)... duplex serial seems to work.
NO! The jumper only needs to be on the RIGHT if you are reprogramming the on-board REAL Propeller. For anything else, the jumper block needs to be on the left. I don't have the board with me - I can upload a picture tonight to we are talking about the same left and right.
The pin mappings you are seeing are the REAL Propeller. P8+ are hard wired to the FPGA data pins - they flash a lot when loading an image.Youcan;t get to those LEDs.
With the jumper on the LEFT, PGM is used when you run px.exe to send an FPGA image down to the 1-2-3 board. RUN is used when you are running your image on the FPGA - it attaches the FTDI RX/TX pins to the FPGA pins that are mapped in the case of the P1V to P30/P31 on the VIRTUAL Propeller.
Thank you for your patience.
I went back to square 1... even reloaded px.spin into the EEPROM. No love from my P123. But I'm going to give it a rest and then try it again.
mindrobots:
I could do that, but I have never had it happen before... and I deeply suspect my own ignorance at this point.
I think I will just order another board... and if it works and this one doesn't then we can swap it out.
I need extra boards anyway, because I have a contest to run AND it is always good to have two boards that both work:)
mindrobots:
It was the entire row of red led's that lit up... I don't see anywhere in the schematic that they are hooked to the real Prop on the board?
(A picture, saving 991 words)
Thank you.
Rich
There is no boot loader in the rbf file I posted, only a loop back test. (The .spin code included for reference).
So proptool will not recognize the fpga but any serial terminal prpgram should receive what was transmitted. We know your USB/FTDI side is ok as it talks to the real prop via px.exe ok.
So if you don't get any response from my loop back code I suspect a problem with the mux/demux circuit.
Sorry for any confusion.
Cheers
Brian
Glad to be awake... horrible dream about playing golf with Arnold Palmer... to get to the next hole, we had to shimmy down a cactus. I don't think it has anything to do with loop back tests:)
Thanks for the explanation... and I have mixed results to report.
Loop back seems to work just fine at 300 and 1200 baud... after that it gets more and more unreliable with increasing baud rates.
The part that we are talking about seems to be the ts3a44159... I found a fellow complaining about the high capacitance of this device: https://e2e.ti.com/support/interface/etc_interface/f/388/t/96956
Regards,
Rich
FYI
Using PST on a Win10 machine here loop back works up to 460800 baud.
Brian
I'm having a problem talking to the FPGA once px.exe has loaded a binary image(.rbf). I think I'm the only one using windows 8.1. So it could be something related to that.
I have some (verilog)VGA code that looks like it should work ... but doesn't. I think it is the
way I'm driving the DAC, but it could be a hardware issue with the board... not likely. I posted a .rbf file for testing in the P123D VGA thread. If it works on another machine but not mine, then there is a component on my board that didn't sit down when it was told to... or which passed batch testing but which didn't make it to real life:)
People keep comparing it to low end entry level products... go look at the other end:)
And... what keeps hobbyists locked out is the way the entire business of FPGAs is structured... it isn't amateur friendly. Intellectual property sales are great for the engineering community, Universities and medium to large sized companies, but they are death to casual conversations and novices. There is an enormous, freely available stockpile of info out there that is almost completely unapproachable. You really should be an engineer to wade into it.
"let me show you how to use an FPGA... but once you have learned, you can't use anything unless you pay me."
Makes perfect sense to the intended audience... of which we are not part.
I would however expect the loop back test to operate reliably way higher than 460800 baud.
Pointing finger at Mux/Demux.
The net result is that I am back to where I started. PX.exe hiccups occasionally but fairly reliably programs the P123 with a P1V from Jac's github... which I also downloaded fresh.
The resulting P1V image is clearly on the board, because when I switch the switch from prog to run... I get the proper LED indicators... one green for Cog0. But the P1V is not recognized by either the PropTool or PropellerIDE.
I cannot get the board to loop through using Ozpropdev's program... at any baud rate.
I have included the compiled .rbf. It could be something in my compile (although given the serial loopback failure, I doubt it:)
Give it a try
Thanks
Rich
Downloaded your code into my 123.
Detected p1V Ok
Green cogs leds react as expected.
Cheers
Brian
so... I could suppose that I have two boards with the same problem and you have a board that doesn't have that problem... or my AMD A8 based HP notebook handles serial in an odd way.
Anyone have this working on a Mac?
Cheers and Beers
Rich
Two different P123 boards.
I'm running Windows 8.1. Ozpropdev has previously confirmed that 8.1 is not the issue. And the .rbf file is not the issue. I'm using the right driver... I think:)
The only other thing I can think of is that I'm running Windows Defender, with all the options...
is there a setting in Defender or somewhere else that can account for this?
Thanks,
Rich