mea culpa --
I am modifying an earlier post, but leaving my original comments below just
to let you enjoy my stupidity. I thought I had the answer as a timing problem
from packetization in the USB chip....but it was much simpler and much stupider.
I had the RTS and DTR lines swapped. Unfortunately, my standard tool, which hooks
to a 9-pin serial cable, had the correct functions going to the correct pins on the
ARM (i.e. pin 4 triggered a transister to pull down RESET, pin 7 to P0.14). My
schematic, however, had these pins mis-labelled....pin 4 was labelled RTS and 7 DTR,
rather than the opposite, which is correct.
This worked fine for me for many years...and I now have to think long and hard about
other places this mistake might have worked into. When I opened up that drawing to
make the prototype with the FTDI chip, I copied the functions to the pins on their
chip, thus swapping RTS and DTR. When I cut the traces and reswapped them on this
board, all works fine.
The reason that it worked fine when the chip was unprogrammed was that it was already
running ISP code, due to the lack of valid code in the flash. That required only a reset
to restart ISP, not a reset/bootsel combo in the proper sequence.
I have no idea how I got those labels wrong in the first place -- I had thought that I
copied the whole thing directly off the help pages of a very early version of FlashMagic,
when it was still labelled as a Phillips ap, but I must have miscopied.
My apologies for all the bandwidth wasted. I hope this thread helps somebody else
avoid this time wasting error.
*** To be perfectly clear, the FT231XS appears to work great with FlashMagic and
the ARM LPC2103 ***
note -- everything below here is incorrect......
>got it -- the problem, anyhow, if not the solution.
>when using the "good" interface, with a standard serial I/O usb cable and a MAX232 and transistors,
>the delay between the release of reset and the transmission of "?" is adjustable with the T1 and T2
>parameters in Flashmagic, and is never less than 450ms. it always works.
>when using the FTDI USB chip interface, the delay is always 340ms, and totally ignores the T1 and
>T2 settings in Flashmagic.
>clearly, the handshake line transitions are packetized, and are not sent until the next transmission.
>The difference between 340 ms and 450 ms must be enough so that the ISP code has not initialized,
>and is not ready to queue up the "?", thus it never receives it. It "works" when the chip is blank because
>there is no valid code onboard, so the ISP code is already running. Even if it reinitializes on the new reset,
>the pointers are in place so that the received autobauding "?" is queued up and responded to. That 340ms
>is the same whether the chip is programmed and doesn't respond to ISP, or is blank and does.
>I have asked my contact at FTDI if they can modify their drivers to flush buffers when they receive a
>transition on the handshaking lines at the PC end...hopefully this is all doable that way, without needing
>a change in microcode in the FTDI chip.
>Another option is to set the driver for a zero-length buffer for packetizing the USB serial I/O. This is woefully
>inefficient, but would work. I thought I had done this, but I had just minimized it. The minimum is 64 bytes,
>and that isn't small enough.
>I'll post here when this gets resolved. If anybody has more wisdom to shed on this, I'd sure like to hear it.
Jeff
I am modifying an earlier post, but leaving my original comments below just
to let you enjoy my stupidity. I thought I had the answer as a timing problem
from packetization in the USB chip....but it was much simpler and much stupider.
I had the RTS and DTR lines swapped. Unfortunately, my standard tool, which hooks
to a 9-pin serial cable, had the correct functions going to the correct pins on the
ARM (i.e. pin 4 triggered a transister to pull down RESET, pin 7 to P0.14). My
schematic, however, had these pins mis-labelled....pin 4 was labelled RTS and 7 DTR,
rather than the opposite, which is correct.
This worked fine for me for many years...and I now have to think long and hard about
other places this mistake might have worked into. When I opened up that drawing to
make the prototype with the FTDI chip, I copied the functions to the pins on their
chip, thus swapping RTS and DTR. When I cut the traces and reswapped them on this
board, all works fine.
The reason that it worked fine when the chip was unprogrammed was that it was already
running ISP code, due to the lack of valid code in the flash. That required only a reset
to restart ISP, not a reset/bootsel combo in the proper sequence.
I have no idea how I got those labels wrong in the first place -- I had thought that I
copied the whole thing directly off the help pages of a very early version of FlashMagic,
when it was still labelled as a Phillips ap, but I must have miscopied.
My apologies for all the bandwidth wasted. I hope this thread helps somebody else
avoid this time wasting error.
*** To be perfectly clear, the FT231XS appears to work great with FlashMagic and
the ARM LPC2103 ***
note -- everything below here is incorrect......
>got it -- the problem, anyhow, if not the solution.
>when using the "good" interface, with a standard serial I/O usb cable and a MAX232 and transistors,
>the delay between the release of reset and the transmission of "?" is adjustable with the T1 and T2
>parameters in Flashmagic, and is never less than 450ms. it always works.
>when using the FTDI USB chip interface, the delay is always 340ms, and totally ignores the T1 and
>T2 settings in Flashmagic.
>clearly, the handshake line transitions are packetized, and are not sent until the next transmission.
>The difference between 340 ms and 450 ms must be enough so that the ISP code has not initialized,
>and is not ready to queue up the "?", thus it never receives it. It "works" when the chip is blank because
>there is no valid code onboard, so the ISP code is already running. Even if it reinitializes on the new reset,
>the pointers are in place so that the received autobauding "?" is queued up and responded to. That 340ms
>is the same whether the chip is programmed and doesn't respond to ISP, or is blank and does.
>I have asked my contact at FTDI if they can modify their drivers to flush buffers when they receive a
>transition on the handshaking lines at the PC end...hopefully this is all doable that way, without needing
>a change in microcode in the FTDI chip.
>Another option is to set the driver for a zero-length buffer for packetizing the USB serial I/O. This is woefully
>inefficient, but would work. I thought I had done this, but I had just minimized it. The minimum is 64 bytes,
>and that isn't small enough.
>I'll post here when this gets resolved. If anybody has more wisdom to shed on this, I'd sure like to hear it.
Jeff