QuickStart Rev A vs Rev B?
David Betz
Posts: 14,516
I just spent a couple of days trying to determine why my RamPage2 driver didn't work. Just to make sure that my QuickStart board wasn't bad I switched to another and the driver worked on the second board. I noticed that the first board was Rev A and the second Rev B. To determine whether the revision made a different I tried a second Rev A and a second Rev B board and got the same results. It looks like my RamPage2 driver doesn't work on Rev A QuickStart boards. What is the difference between these two revisions? Is there anything that would explain why the driver would work on Rev A but not Rev B? It looks like I have a number of QuickStart Rev A boards that aren't going to be useful to me.
Edit: Looks like I have three Rev A QuickStart boards that won't work with my RamPage2 driver. I also wonder if this is one of the problems I was having with the Propeller Memory Card a while back.
Edit: Looks like I have three Rev A QuickStart boards that won't work with my RamPage2 driver. I also wonder if this is one of the problems I was having with the Propeller Memory Card a while back.
Comments
The first QuickStart boards only had 32K EEPROMs could this make a difference in your driver (I thought I read some C drivers use the upper EEPROM)?
I have a program to test between 32K and 64K boards if you think the EEPROM could be the problem.
The 32K versions weren't made for very long so it seems odd you would have three of them.
Quickstart Rev.A: FT232 and Buffered Rx/Tx lines for Propeller.
Quickstart Rev.B: FT231 and Buffered Tx line to Propeller (pull up not required).
Consequences:
Rev.B boards will no longer spit random characters to the terminal Yahoo!!!
Rev.B boards will not be found on older Linux OS (same for ActivityBot).
Propeller GCC can use up to 54KB of a 64KB EEPROM for XMMC programs.
I'm guessing the post really meant Older Linux systems with older FTDI drivers that pre-date the FT231 ?
I think you have the reverse problem - you can see FT231, but not FT232, right ?
What does a Terminal pgm do - can that find the FT23x and echo chars ok, and control the RST line ok ?
Did you try a FTDI driver update ?
- All units have 64 KB EEPROM
- Uses an FT231X series USB to serial converter
- Supports USB charging specification, so it can be powered from a USB charger
- Can be programmed from the 40-pin header
- Uses a single-bit buffer to prevent the FT231X IC from parasitically powering the Propeller Microcontroller through an ESD protection diode
- The FT231X IC's receive pin is directly connected to the Propeller Microcontroller, which reduces the chances of the USB to serial converter receiving random data when the Propeller hasn't initialized the serial port
- Requires newer FTDI drivers
- The /USB_PWR_EN includes a protection diode, so it can be externally driven high or low
- Driving /USB_PWR_EN high (usually 5 V, depend on exact voltage of USB supply) removes USB power from the 3.3 V regulator input
- The Propeller Microcontroller is connected to the 3.3 volt supply through a 0-ohm resistor, which can be removed to measure power consumption
- The 40-pin header allows connections through the top and bottom sides and includes pin function labels on the bottom side
- Labels and marking on the board are for the Propeller QuickStart from Parallax and include the Open Source Hardware logo
We've also found that the Linux kernel drivers for the FT231X intermittently lose data in Ubuntu 13.04 (kernel 3.8) but work fine in Ubuntu 13.10 (kernel 3.11). David Carrier
Parallax Inc.
Thanks,
David
rampage2_sram_xmem.spin
Very cool!
Did this require a different part to use as the header?
It looks like pins bottom out at the PCB on Rev. A board. Were drilling the holes and moving the traces the only changes required to allow connection from the bottom of the board?
Sorry David, I suppose this is a bit OT. I sure don't see any reason why your driver would work on one and not the other.
P0 - P7 are all touchpad pins. Did the geometry of the pads change? It doesn't look like it, but the routing to the pads had to change to make the extra holes under the header.
I don't see anything off hand that would make it work in a Rev A board but not in a Rev B board. The changes are all related to power switching and the serial/USB port on P30 and P31. Since you aren't using P30 or P31 the change to the FT231X shouldn't make a difference. The voltage regulator itself didn't change, but my best guess is that there is something power related that is stopping it from working. The SST26VF016 devices can instantaneously change their current draw from less than 15 microamps in standby to typically 12 millamps while reading or up to 30 millamps when writing or erasing. The voltage pumps for programming and erasing can also create current oscillations that can mess with the 3.3 volt regulator's feedback loop. As a test, try connecting a 30 to 50 ohm half-watt resistor on J2 of the RamPage2 from VDD through to GND. It will draw a large amount of current so that current swings are less significant of a percentage of the total current draw. If that makes a difference, put more and larger bypass capacitors next to the flash memory and perhaps one large capacitor near the VDD input from the QuickStart.
— David Carrier
I think David says it works on Rev B, and not Rev A, but Rev A is ok in 4 bit mode test ?
When I experimented with stacking 8 23K256 (I think that's what they're called) chips to form an 8-bit bus, I found any one chip would work but when accessing all chips at once I'd get an error. Adding additional caps near the Vdd pins of the SRAM solved the problem (as David Carrier suggested). IIRC, I needed to more than one size. I think I used a 0.1uF and an 1uF cap near the Vdd pins. I think I've made five different multi-SRAM boards and this was a common problem.
Yes, but it could be an idea to confirm caps do actually fix the problem ?
You could also check if adding some NOPs to expand the critical times a little helps ?
(I've seen lowered clocks help on ribbon cable programmers)
:loop rdbyte data, hubaddr add hubaddr, #1 shl data, sio_shift andn outa, sio_mask or outa, data or outa, sck_mask andn outa, sck_mask djnz count, #:loop:loop rdbyte data, hubaddr shl data, sio_shift andn outa, sck_mask andn outa, sio_mask ' Might be able to now merge these two lines or outa, data add hubaddr, #1 or outa, sck_mask ' assumes CLK _/= is active edge. djnz count, #:loop andn outa, sck_mask ' optional, gives same exit condition as above:loop rdbyte data, hubaddr add hubaddr, #1 shl data, sio_shift andn outa, sio_mask or outa, data or outa, sck_mask nop nop nop nop nop andn outa, sck_mask djnz count, #:loopI don't have a 30-50 ohm 1/2 watt resistor so I haven't tried David's suggestion yet. I'll have to drive by RadioShack later to pick one up.If it changed, it confirms edge timing matters
With clk-slew/bounce issues, it can also help to shift the Data well clear of the CLK (above, I moved a can-go-anywhere line to do this, but you can also pack with NOPs for testing like this :
:loop rdbyte data, hubaddr add hubaddr, #1 shl data, sio_shift andn outa, sio_mask or outa, data nop nop nop nop or outa, sck_mask nop nop nop nop nop andn outa, sck_mask djnz count, #:loopIs A or B "better?
LOL..the comment about stopping by RS to get a component is ironic considering the situation at RS.
I would agree that having a B&M presence matters.......sometimes you need something RIGHT NOW!