USB download cables

Dr_Acula · 2011-11-18 19:58

As my presbyopia gets worse I am having to face certain changes in my lifestyle - including the inability to solder FT232 chips

I did a search for breakout boards using the FT232 - including the prop-plug, and they all seem much more expensive ($12) than USB to RS232 cables ($2).

But as so many have found, many RS232 cables do not work. So I thought I would some experiments and try to find out *exactly* why some do not work.

My test setup involves some simple vb.net code. I am using a USB to RS232 cable that I know does not work with the propeller.

Open a port

        SerialPortName.PortName = "COM4"
        SerialPortName.Open()

Set the DTR line "true"

        SerialPortName.DtrEnable = True

or "false"

SerialPortName.DtrEnable = False

and close the port

SerialPortName.Close()

I have found out several interesting things:

1) The voltage levels on this cable are not valid RS232. Real RS232 resting volts are minus 3 to minus 12V, and when data is transmitted the voltage should be +3 to +12V. On this cable, resting volts are 0V, and data is +5V.

2) If you set DTR to "true", ie a positive voltage, and then close the port then it goes false. Open the port again and it goes back to what it was before. I wonder if this could explain some of the resets that get reported on the forum from time to time?

For this experiment though, I think #2 is not relevant. I think the issue here is the non standard RS232 voltages.

Most reset circuits use a series capacitor, eg 10nF and a resistor, eg 10k. This acts as a high pass filter and passes through a voltage spike when the DTR line changes state. The voltage spike is positive on the positive edge and negative on the negative edge. Most circuits pass through the positive spike into a transistor, though there was some discussion on one of the Z80 emulation threads where Pullmoll found that there was more compatibility between BST and the Spin Tool if you reset on the negative edge.

My theory is that the transition from -12 to +12V produces a much bigger kick (translating to a longer reset pulse) than a transition from 0 to 5V.

I am going to do some experiments with a max3232 and see if passing the DTR line through one of the spare max3232 gates will work better. My idea is that this will produce a voltage change from 3V to 0V which will be the same regardless of the RS232 voltage level, and hence the high pass RC network can be tweaked to get a reset.

If this works, I'm thinking that a $2 USB cable plus a $1 max3232 plus a $1 D9 socket work out cheaper than a FT232 breakout board plus USB cable or the prop plug.

Does anyone have links to the various download circuits - I think that somewhere there is one done with just transistors. And I seem to recall different RC values to 10nF/10k (the FT232 for instance outputs 5V and a max3232 outputs 3V so ? the 10k needs to be increased by 5/3 to 18k)

Input and thoughts from others would be most appreciated.

Cluso99 · 2011-11-18 20:50

Your theory of +/-12V does not hold because the transistor reset circuit works on a 3v3/Gnd on an FT232RL.

I discussed what happens on this thread recently http://forums.parallax.com/showthread.php?133362-Why-do-we-need-the-transistor-reset-circuit-for-the-USB-devices-(FT232RL-CP2102)&highlight=transistor+reset

The reset pulse occurs when DTR goes from active to inactive. So, with your program, it should reset when the VB program exits. However, if you have the reset program as per the diagram (series cap 10nF to base and 10K to ground) and the circuit is RS232, then you will actually reset on the transition from inactive to active (because the RS232 is inverted).

Therefore, this is most likely the issue as to why your cable does not work. Dont forget you will also need to invert the Txd & Rxd too, although it is possible the code in the prop could cater for this inversion (need to check the rom code - its been published).

So, to try your cable, use an inverter on the DTR before the transistor, and likewise on TXD & RXD. A 74HC04 should do. If this works, try removing the TXD & RXD inverters and see if chip permitted the inverse to work. Anyway, if the DTR works, we can find a simpler way for the transistor circuit - [edit] try just a series cap 10nF and not resistor or transistor.

Cluso99 · 2011-11-18 21:25

Just check the prop booter code. After reset it expects the RXD pin to be low (active) for a short time. If not, or its too long, then booting continues from eeprom. This means that the RXD must be TTL level (i.e. invert RS232 level) and that it must occur within a certain time period of the end of reset and not be too long either. So there is a time window that the RXD pulsing must be detected within or it will fail to boot from the serial port.

Dr_Acula · 2011-11-19 00:54

Thanks Cluso - I'm rereading that link of yours.

I have had a eureka moment - this works with both a real RS232 (I use an older PC) and my cheapie USB to RS232 cable which cost $2.

I'll draw up the schematic, but essentially the DTR line goes through the max3232 and then into the 0.01uF and a BC547, with a 10k pulldown on the base.

RS232 is immensely confusing as there are all sorts of different ways of describing a signal. It can be "true" or "false". It can be -12V or +12V. It can be active or inactive. We can talk about the real RS232 value, or the value after it goes through the inverter in the max3232. So I must confess that after rereading Cluso's thread (which I contributed to at the time), I am even more confused as I am not sure what voltages are being referred to.

One can't even refer to volts, as the cheapie USB to serial device does not even have valid RS232 voltage levels.

So, to try to clarify things, my understanding is that the "resting" value of a signal is -12V. That is also called "inactive" and in vb.net, it is called "false".

On a cheapie USB cable, that value is 0V. Now, this is where things might get confusing, because if you unplug a RS232 cable with -12V on it, you might generate a spurious reset because the -12V will change. But unplugging a cheapie USB RS232 cable might not generate a reset, because 0V will change to open circuit (probably interpreted as 0V).

I assume a reset pulse goes from "inactive" to "active" to "inactive". On a real RS232 line, that is -12V, +12V, -12V. On a cheapie USB cable, that is 0V, 5V, 0V.

The max3232 inverts that, so the signal now goes 3V, 0V, 3V. The transistor inverts it again. What I think that means is that the leading edge generates a brief negative voltage, and the trailing edge generates a positive voltage, which the transistor then inverts.

So - my interpretation is that if you generate a reset pulse, it is the trailing edge that actually generates the reset.

I'll draw this up in a schematic and repost. I am hoping this could save $10 on a propeller board.

Dr_Acula · 2011-11-19 01:23

Addit - multiple tests later and I still have a problem

"Write error" with the cheapie USB to serial cable when using the Prop tool.

So what works:
BST and a real RS232 port
BST and a cheapie USB to serial cable
Prop Tool and a real RS232 port

What does not work is
Prop Tool and cheapie USB to serial cable.

However, both BST and the Prop Tool find the Propeller using both cables.

All very confusing. I suspect we might need to revisit Pullmoll's research.

There is a reset pulse:

1) Do you reset on the leading edge or the trailing edge?
2) What is the optimum timing (in milliseconds) for the reset pulse - or more specifically, the pulse that actually appears at the propeller pin?

Next experiment - vary the RC timing network - either decrease or increase the resistor?

Cluso99 · 2011-11-19 01:25

Quick lesson of RS232...

For the signals DTR, DSR, RTS, CTS, DCD & RI... the RS232 signals are +ve when active/true and the TTL equivalent is inverted meaning 0V/GND is active. When inactive/false the RS232 is -ve and the TTL is inverted meaning +V is inactive/false. This is why the UARTs (which is TTL) label /DTR etc (note the inversion meaning low active).
For TXD & RXD, a start bit (and 0 bits) is +ve for RS232 and 0V/Gnd for TTL, and stop (and 1 bits) is -ve for RS232 and V+ for TTL.

So, to use your cheapie cable, you will need to invert both the TXD & RXD, and the same with the DTR line and then use the rc/transistor circuit. However, for DTR, I think that you can just place a series 10nF capacitor (or 100nF) in series with DTR and the prop reset (as long as the voltage is only a little over 3V3) - perhaps a small 470R in series may help protect the props reset. If you use a 74LV04 and the transistor reset cct all should be fine.

Dr_Acula · 2011-11-19 03:09

Thanks Cluso - that was what I figured as well.

I tried increasing the pulldown resistor on the base. I calculated that changing +/-12V to +/-3V the ratio ought to increase the 10k to about 27k. Then I checked the prop plug schematic and they use 33k so I put in a 33k instead of the 10k.

Same problem though. BST works fine with the real and the cheapie USB serial ports. The proptool works fine with a real RS232 but not with the cheapie plug.

All most odd.

The transistor, cap and resistor are the same as the schematic for the propplug http://www.google.com.au/url?sa=t&rct=j&q=prop%20plug%20schematic&source=web&cd=1&ved=0CB8QFjAA&url=http%3A%2F%2Fwww.parallax.com%2Fdl%2Fdocs%2Fprod%2Fprop%2F32200-32201-PropClipPlug-v1.3.pdf&ei=O4zHTuBCrq2JB8-R9PwP&usg=AFQjCNHjeQxQ89Q-PouhufzAHNxKCANH9w (scroll down a bit in that pdf).

The only thing I have different is I don't have 150 ohm resistors.

What I can't understand is that every RS232 line is buffered through a max3232 - the reset, tx and rx. So why is the behaviour different for the proptool running a real RS232 vs a cheapie RS232? The TTL signals on the other side ought to be the same - how would the propeller know or care whether the RS232 resting value is -9V or -12V or 0V? It is isolated via the max3232. Unless the max3232 is unhappy about 0V as a RS232 logic level. But that doesn't explain why BST works.

I found this thread http://forums.parallax.com/showthread.php?103862-Propeller-Tool-Write-Failure-on-COM4

If BST works but the proptool does not, I am suspicious of a timing difference. Interesting in that thread above that the problem got fixed but not 100% sure what the fix was.

Are there specifications around somewhere for the download timings?

What are you suggesting re the capacitor? Are you suggesting leaving out the transistor? If so, that would reset on the leading edge, not the trailing edge.

Addit: More information. The failure point is the Proptool plus Cheap USB cable and a large program. So I tested this with the following tiny program:

CON

  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

PUB Main
  Toggle

PUB Toggle
dira[16]~~
repeat
!outa[16]
waitcnt(3_000_000 + cnt)

This does download and run on the cheapie usb serial plug.

So the problem is with big programs and the cheapie plug and the proptool.

BST works fine.
Big programs work fine on the proptool using a real serial port.

So I think that thread http://forums.parallax.com/showthread.php?103862-Propeller-Tool-Write-Failure-on-COM4 may be quite relevant. I ran the program in post #4 on that thread - the only thing that stands out is the rx buffer size is a lot larger on the usb serial port vs the real usb port. I see that parallax had a diagnostic program that gave a more verbose answer.

Computer Name:         JAMESHOMEXP
User Name:             Administrator

--------------------------------------------------

Long Name:             Communications Port (COM1)
Short Name:            COM1
Provider Capabilities: DTR, RTS/CTS, RLSD, Parity, XON/XOFF, Settable XChar, Total Timeouts, Interval Timeouts
Settable Parameters:   Parity, Baud Rate, Data Bits, Stop Bits, Handshaking, Parity Checking, RLSD
Settable Baud Rate:    75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 7200, 9600, 14400, 19200, 384000, 56000, 115200, 57600, Programmable
Max Baud Rate:         Programmable
Settable Data:         5-bits, 6-bits, 7-bits, 8-bits
Settable Stop Parity:  1 Stop Bit, 1.5 Stop Bits, 2 Stop Bits, No Parity, Odd Parity, Even Parity, Mark Parity, Space Parity
Current Tx Queue:      0
Max Tx Queue:          0
Current Rx Queue:      4096
Max Rx Queue:          0

--------------------------------------------------

Long Name:             Communications Port (COM2)
Short Name:            COM2
Provider Capabilities: DTR, RTS/CTS, RLSD, Parity, XON/XOFF, Settable XChar, Total Timeouts, Interval Timeouts
Settable Parameters:   Parity, Baud Rate, Data Bits, Stop Bits, Handshaking, Parity Checking, RLSD
Settable Baud Rate:    75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 7200, 9600, 14400, 19200, 384000, 56000, 115200, 57600, Programmable
Max Baud Rate:         Programmable
Settable Data:         5-bits, 6-bits, 7-bits, 8-bits
Settable Stop Parity:  1 Stop Bit, 1.5 Stop Bits, 2 Stop Bits, No Parity, Odd Parity, Even Parity, Mark Parity, Space Parity
Current Tx Queue:      0
Max Tx Queue:          0
Current Rx Queue:      4096
Max Rx Queue:          0

--------------------------------------------------

Long Name:             USB-SERIAL CH340 (COM4)
Short Name:            COM4
Provider Capabilities: DTR, RTS/CTS, RLSD, Parity, XON/XOFF, Settable XChar, Total Timeouts, Interval Timeouts
Settable Parameters:   Parity, Baud Rate, Data Bits, Stop Bits, Handshaking, Parity Checking, RLSD
Settable Baud Rate:    75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 4800, 7200, 9600, 14400, 19200, 384000, 56000, 128000, 115200, 57600, Programmable
Max Baud Rate:         Programmable
Settable Data:         5-bits, 6-bits, 7-bits, 8-bits
Settable Stop Parity:  1 Stop Bit, 1.5 Stop Bits, 2 Stop Bits, No Parity, Odd Parity, Even Parity, Mark Parity, Space Parity
Current Tx Queue:      0
Max Tx Queue:          0
Current Rx Queue:      68992
Max Rx Queue:          0

It seems to suggest to me that if big programs are the problem for the proptool, somewhere in the download process is a handshaking protocol that is not working (and which BST has addressed). Maybe this is not to do with the reset line at all. Maybe there is a timing delay in the download process that does not work with these cheapie cables? Maybe the proptool expects an acknowledge and it takes too long to arrive?

Hmm- I just noticed something. That thread was in 2008, and my proptool program is a little old - it says "copyright 2004-2008". Maybe maybe I need to get a newer version. BRB!

Addit - no same problem with the latest version. Lucky I have a real RS232 port (&BST)to compare with otherwise debugging would be very difficult.

Cluso99 · 2011-11-19 04:05

the latest proptool has some time adjustments for dtr and you can also change to use rts or both. It also comes with a new ftdi driver and other updated goodies.

The other thread is interesting. Btw I know brad spent a lot of time trying to ensure bst woulld work in all situations. He also has a faster downloader option.

Since you are on a real port, perhaps there is some form of buffer overrun happening. Try proptool v1.3 first.

Dr_Acula · 2011-11-19 04:24

Hi Cluso,

Thanks for all your help here. I got the latest version and tried tweaking the DTR delay time but nothing obvious works.

I am thinking this is getting to the stage of asking for some help from Parallax. I have a serial port sniffer program so I can watch the data go through. When using the real serial port there is a huge amount of data sent, and there are ack bytes coming back.

This is the first part of the data being sent - it looks like a a bunch of FE and FFs until there is an ack, and then it starts sending. I truncated the listing as it is quite long - once the data is going out it works fine.

Data out via real serial port:
[code]
Port opened by process "Propeller.exe" (PID: 1608)

F9 FE FF FE FF FF FF FE FE FF FF FF FF FE FF FE

Cluso99 · 2011-11-19 14:03

Drac: You have inverted all 3 lines with the MAX3232 chip haven't you, and then fed the inverted DTR signal to the transistor reset circuit?

To lengthen the reset pulse, you can either increase the resistor or capacitor, and to shorten the reset pulse, reduce the resistor or capacitor. Remember, the PropTool uses the DTR going inactive to trigger the reset pulse. DTR remains inactive while the PropTool is downloading the code. This is not the normal way of doing things. It was done this way to permit other programs to be loaded in windoze following a download, without causing the prop to reset.

The propeller rom code seems very specific for the initial timing from reset to looking for the first data pulse, and this is very dependent on the RC oscillator of the prop chip and will vary between chips.

Dr_Acula · 2011-11-19 15:24

Drac: You have inverted all 3 lines with the MAX3232 chip haven't you, and then fed the inverted DTR signal to the transistor reset circuit?

Yes that is correct. And the transistor has a 33k and a 0.01uF capacitor which is the same as the Gadget Gangster USB board.

And it is worth pointing out that everything works perfectly with BST. BST can download and run any size program. So that means a lot of things must be correct with the hardware.

I suspect Brad did a lot of experimenting to get things right.

So - what could be different between BST and the Spin tool?

Data certainly goes through with the Spin tool as it is possible to download small programs. But not big ones and this is exactly the same fault as described in that thread from 2008.

I am thinking it is either the reset pulse, or it is differences in delays with the ack bytes coming back. As an aside - if we can solve this it might lead to the ability to do wireless downloads.

Could you please describe that DTR pulse even more precisely? Define "active" and "inactive" for instance.

Here is my understanding which I think is the same as you describe. Normally DTR is at -12V. That could also be called "inactive" or "false". A reset pulse sets the DTR line active (+12V) and then inactive (-12V). So it goes inactive/active/inactive.

Studying the transistor circuit, I believe that the reset to the propeller chip will be triggered by the "active" to "inactive" transition, as you say.

I plugged 33k and 0.01uF into a 555 timer and got a time of 0.22ms. I know that won't be quite correct as there is leakage into the base plus there is a transition of 0.6V vs 2/3 of VCC on a 555, but if anything, the leakage into the base may make that time even shorter.

In the Spin tool the default value is 90ms which is much longer than that reset pulse. FWIW I tried a wide range of values in 10ms steps with no change in the response.

This is the serial port monitor program with a BST download of Kyedos - again I truncated the data going out as it is a long file.

Data going out
[code]
Port opened by process "bst.exe" (PID: 2992)

F9 4A 25 D5 4A D5 92 95 4A 92 D5 92 CA CA 4A 95

Toby Seckshund · 2011-11-19 15:39

@ Dr_A Hmm.. the eyesight....

I wish there was a HID complient driver for Win XP so that I could play on the works machines. One of my compatriats had sought music dowlnoads, this caused a ban on my local admin rights, and now I want a simpistic way of pluging in a USB( to Prop) interface.

The way that RS232 talks to the world will never be sorted out, just accept it.

PS I have just got a pic32 DuinoMite, from DonTronics, If the spec of 128 KB working code and it's VGA, proves less than equal that the Prop2 promises, then the we will have such a flexible system.

Dr_Acula · 2011-11-19 15:56

I wish there was a HID complient driver for Win XP so that I could play on the works machines.

This is one reason I would like to get this working with the USB to serial device - I never installed any software for this device. I just plugged it in and XP recognised it. I think these adapters are so universal that they have added the drivers to XP.

The way that RS232 talks to the world will never be sorted out, just accept it.

Having proved this works with BST, I am coming to the conclusion that this is a SpinTool problem, not a RS232 problem.

Specifically, I think somewhere there is a timing issue in the SpinTool.

In an ideal world, a downloader would be rather timing agnostic - eg xmodem, where it will wait for minutes for an ACK. I am also thinking of wireless RS232 modules for wireless downloads, where there are going to be delays of up to 60ms for an ACK. The problem with wireless links is they only have Tx and Rx and no reset line. But I think that could be solved too, eg if you had Kyedos running and it detected a "reset packet", performed a software reset, and meanwhile some more data is streaming in from the wireless module which the propeller then uses to set up a download.

I'd be very interested to see a datasheet that explains the download protocol for a propeller. What data it expects, what delays are inbuilt, what is the ACK (?FE or FF).

I'm off to study this webpage http://propeller.wikispaces.com/Download+Protocol

Cluso99 · 2011-11-19 23:24

Drac: Active means On. In RS232 that means DTR=+V and Inactive means Off and -V. This is then inverted for TTL so Active On is now 0V and Inactive Off is 3V3.

The reset circuit only turns on the transistor for a short time when /DTR goes from 0v to 3v3 because its TTL. This means when DTR goes from Active On to Inactive Off. I cannot explain any simpler than this. If in doubt, look up RC circuits for an explanation. There is NO reset pulse when DTR goes Inactive Off to Active On. This is just the way the prop works which does allow programs to be changed without causing a reset, because the default on the serial port when closed is DTR Inactive Off.

What it seems could be an issue is the opening of a file in PropTool is taking too long if the file is large. Certainly, I think you have found a bug with PropTool. BTW the base-emitter resistor should be 10K from the Propplug circuits I have seen recommended. I would think that your 33K would only help solve the problem because it would extend the reset pulse because this is used for the decay of the charge on the 10nF capacitor.

I cannot actually see any reason as to why your circuit should not work with PropTool.

Toby Seckshund · 2011-11-20 01:46

At the point of the serial interigations the Prop will be running on RCFast and so will have quite a speed variation to take into account. This should mean that the timings are none too critical. I once experimented with a manual reset and load, just to see if it was possible to catch it at the right time, it worked about one time in ten.

I have a few USB to '232 converters that do not get spotted by XP, and as they have no makers name on them... I suppose I will have to lever one of them apart.

(One correction - I have a DuinoMite-Mini that has the Basic preloaded, as soon as I can find a mini USB lead I will have a play. Quite an Aussie project, even if it was manurfactured somewhere around Bulgaria (even came with a Koala wearing a hard hat and waving a flag).

Dr_Acula · 2011-11-20 02:45

@Cluso, that is exactly the way I understand how it all works. Attached is the schematic - nothing special really. The fact this works perfectly with BST but not with the Proptool does reluctantly lead me to the conclusion that the solution lies in changing the code for the Proptool. This problem seems so similar to that one described two years ago.

@Toby, good point re the prop running on the RC network rather than the xtal (would the prop know what xtal it had anyway?). So the prop has to somehow work out the baud rate and I think that is what is going on with that wikispaces link a few posts ago. And if so, what if, say, the USB to serial device decided to send through the serial bytes with a wait state somewhere in the group?

I don't really know at this point - I think you almost need a storage CRO to compare the Proptool and BST. Even the compiled data is different. Is there a way to send a binary file - eg compile with the Proptool to a .binary file but send that file via BST?

Toby Seckshund · 2011-11-20 05:41

I have just read over the wiki you mentioned, it certainly indicates the way that the comms is set up without bit rates being fixed, and why those port sniffs you posted have all FFs and FEs.
I would have just assumed that they were all errors!

(I glanced over the startup sequence when I was trying to automatically switch out the EEPROM, to get back the pins, on the "different memory experiment board" a while back. I didn't follow it up much as I found it so much easier just to use the H-Sync signal to do the work via a diode pump. The activity on the EEPROM pins didn't do as I expected and the odd glitch here and there was enough to fool the latch at the wrong time).

I will have to get a printout of the entire start up sequencing and code, and find a quiet corner (and presbyopia will set a requirement for glasses here too)

EDIT. I really miss my magnifer lamp, I should have invested in a proper metal angle poise type, rather than the cheap platic copy. It only lasted about 2 years before the main knuckle snapped.

Cluso99 · 2011-11-20 16:25

During the bootup and download process, the prop uses the internal RC network. No xtal is required for this to work as it is just not used. The actual comms from the pc is bit banged (from what I understood) and the timing is detected by the prop on this bit banging synchronisation. I do know Brad has a double speed download (Drac - would you try this?).

Drac: There is one thing I would do, just in case, on your circuit. Change the resistor pullups on P30 & P31 (led resistors) to 3K3.

I certainly think it is time to ask for Parallax engineering help. If we can nail this, then I think we may be able to simplify some of the designs to remove the transistor cct, at least as an option. It then would make the $4 CP2102 modules a cheaper alternative. FWIW my new designs place the transistor/resistor/capacitor cct on the board with a solder link to bypass it - makes using a cheaper propplug alternative easier.

Eyes: My brother gave me his magnigying glasses (not sure of their correct term). They are a set of magnifying lens on a hinge and a strap that goes around the head - they are uncomfortable but they do work nicely with my normal computer glasses.

Dr_Acula · 2011-11-21 13:49

Hi Cluso,

Re the resistor pullups, I have two circuits - one has the 220R led resistors and the other circuit has no leds and no resistors and the problem is the same on both so I think it eliminates that as a variable.

Who would you suggest to ask in parallax engineering?

Ariba · 2011-11-21 18:22

I have seen this problem with the PropTool also, when I tried to use a USB-PIC as an USB to serial interface.
I have an older version of the Prop Tool (v1.05.5) which does it right. There was a big change with the loader later (I think to version 1.1) from then on I got the errors for longer downloads. It may be that some timeouts are set too short in the loader code on PC side.
The FT232 is relatively fast and has a bigger buffer than cheaper USB to serial converters, that is maybe the reason it works with it.

You can't really do anything on the hardware side, this is a software driver problem.

Andy

Oldbitcollector (Jeff) · 2011-11-21 18:30

@Dr_A:

Personally, I applaud your efforts to find alternative methods of loading the Propeller. Anything which removes the necessity of more expensive FTDI interfacing is a win in my book. Keep at it!

OBC

Dr_Acula · 2011-11-21 19:57

Ariba

I have seen this problem with the PropTool also, when I tried to use a USB-PIC as an USB to serial interface.
I have an older version of the Prop Tool (v1.05.5) which does it right. There was a big change with the loader later (I think to version 1.1) from then on I got the errors for longer downloads. It may be that some timeouts are set too short in the loader code on PC side.
The FT232 is relatively fast and has a bigger buffer than cheaper USB to serial converters, that is maybe the reason it works with it.

That sounds a very logical explanation. It is exactly what I am finding - it works with small programs but not with big ones. And if the packet size were smaller than the buffer size then the data would be lost. This could explain the varying behaviour with different chips/different USB adapters. And maybe it is *not* due to the DTR line at all?

I am looking at the prop-to-prop loader code on the first post of this thread http://forums.parallax.com/showthread.php?86311-Propeller-Loader&p=591445#post591445

So we have two theories to test out;

1) The packet size is too large for some devices and
2) The timeouts are too short in the PC downloader program.

I am starting to understand the 3BP protocol a bit better after reading the spin code and http://propeller.wikispaces.com/Download+Protocol

FE is 0 and FF is 1 for one bit per byte sent, but that involves a cunning trick, because 001 is 0 and 011 is 1 and yet FE is 11111110. The trick is that firstly the LSB is sent first, and secondly, the 'start' bit of the 8N1 serial download is included. The start bit is 0, so that is the second zero.

The wiki article goes on to explain how to pack 3 bits into a byte and again, you might think how could you fit 3x3=9 bits into 8 bits, but it includes the zero start bit as well. (8N1 is actually 10 bits). So knowing how this works, I think one could write a reverse translator to take the bytes from the serial port sniffer and turn them into the actual bytes that were sent. I think if you can translate the data stream you can try to work out where BST and the Proptool differ.

Ariba, would you happen to have a copy of that old 1.05 version which worked? If so, would you be able to post it here?

Cluso99 · 2011-11-21 22:37

I am unsure who you could ask at Parallax. There should be a pointer on the parallax home page.

What does your program that fails do? As long as it will give an indication out the P30/31 serial pins to PST, I could download the binary here using a CP2102 and the reset transistor cct and see if it fails here.

Ariba · 2011-11-22 00:48

Dr_Acula wrote: »

Ariba, would you happen to have a copy of that old 1.05 version which worked? If so, would you be able to post it here?

Here it is. It's just the Propeller.exe, you can rename this and copy it into a newer PropTool folder. So you get access to all the new library objects.

Andy

Dr_Acula · 2011-11-22 03:10

Thanks++ - I'll check it out and let you know.

Dr_Acula · 2011-11-23 00:07

Ariba said

I have seen this problem with the PropTool also, when I tried to use a USB-PIC as an USB to serial interface.
I have an older version of the Prop Tool (v1.05.5) which does it right. There was a big change with the loader later (I think to version 1.1) from then on I got the errors for longer downloads. It may be that some timeouts are set too short in the loader code on PC side.
The FT232 is relatively fast and has a bigger buffer than cheaper USB to serial converters, that is maybe the reason it works with it.

Well, guess what?

Your version 1.05.5 works!!!!! Thankyou thankyou thankyou!

It works perfectly for all downloads.

So - to analyse this, a version from 2007 works fine and a version from 2011 does not work. So I suspect that this is exactly the same problem Ariba found with errors for longer downloads. I also get problems with longer downloads. Something changed and Ariba suspects it was around version 1.1.

I think it is time to put in a formal request for help from Parallax.

But meantime, I wonder if I could ask for help from this forum - does anyone have any old versions of the Proptool lying around, particularly around version 1.1?

Many thanks in advance.

Ariba · 2011-11-23 00:44

Dr_Acula wrote: »

...
Well, guess what?

Your version 1.05.5 works!!!!! Thankyou thankyou thankyou!

Your welcome .-)

Just a warning: Not all code can be compiled with this old version, it misses the $ statement for the current address in PASM.

Perhaps there is a changelog text for the PropTool somwhere on the Parallax site. I remember the changes were mainly done to exclude some COM ports from the searching for a connected Propeller. You can see this according the [Edit Ports] button in the Preferencies. But they changed also the whole download code logic at the same time. To make it work better - was the intention....
I think the Programmer was Jeff (don't know the full name).

Andy

Unsoundcode · 2011-11-24 06:32

Dr_Acula, this may be outside of the scope of your tests and discussion but I was curious to know if the "bad" cables worked with the Propellent.dll outside of the Proptool IDE. Does BST use the Propellent or a propriety loader.

Jeff T.

Dr_Acula · 2011-11-24 15:30

Good question. I'm not sure what BST uses - I'll need to check it out.

I put in a formal request to Parallax yesterday for some technical assistance. I'm hoping that it will be possible to work out exactly which version of the proptool stopped working and then work out what the change was.

USB download cables

Comments