RetroBSD

Battery backup current: it is not an issue, but I've done a simulation just now:

1. when both Si epi and VCC powered on:
battery current +250pA (leaking the battery)
2. when battery_diode_epi and Vcc_diode_schottky and VCC powered on:
battery current -15pA (charging the battery)

1. when both Si epi and VCC "shorted" (power off, not realy a proper state):
battery current +257nA (sourcing the rtc)
Vcc_diode current -17pA (leaking to gnd)
2. when battery_diode_epi and Vcc_diode_schottky and VCC shorted:
battery current +262nA (sourcing the rtc)
Vcc_diode current -5.2nA (leaking to gnd)

Result: you are right, use 2xSi planar epi in smd 3pin.

PS: it depends on the retrobsd power on/off ratio. When powered on >20x longer than powered off, the shottky in Vcc is better

_________________
Pukao Hats Cleaning Services Ltd.

Or we can ask users to let it run forever, then no backup will be needed

_________________
http://jaromir.xf.cz/
https://hackaday.io/jaromir/

The rtc will not be used for a long time I guess. We do not have I2C driver - tricky stuff with almost all oses I saw.

_________________
Pukao Hats Cleaning Services Ltd.

what about using different rtc? If IIC is problematic, then SPI, for example?

_________________
http://jaromir.xf.cz/
https://hackaday.io/jaromir/

We do need I2C anyway. So let it be - it will work as a motivator then

_________________
Pukao Hats Cleaning Services Ltd.

UEXT connector - the Olimex guys using this 10pin connector for connecting dozens of various gadgets.
It is a 10pin connector with RS232/SPI/I2C/Vcc/Gnd pins. Maybe worth of considering?
https://www.olimex.com/Products/Modules/

_________________
Pukao Hats Cleaning Services Ltd.

Hi Jaromir,

I occurs to me that either CPU or DRAM could be on the backside making much more room for option connectors and other stuff.

Good ideas about expansion connector, but most are pretty simple and not well thought out regards placing of power, ground, clocks, crosstalk issues, etc.

Also, some user defined pins are often very useful. We have a 20 pin bus that has proven pretty useful in that many different devices can just be plugged in without any bus interface device being required.

Making whatever bus work over commonly available flat cable connectors seems like a good idea. No backplane required at all .

Wiz

Such connector for flat ribbon cable would require a 2x15pin header with second row all with GND. Not sure it fits..
Moreover, somebody shall define the BUS then, not easy task
SDram on the bottom - I like it as it saves space and shortens the tracks.. The worst for mcu decoupling, however..

_________________
Pukao Hats Cleaning Services Ltd.

Hi Pito,

Every other pin can be extended to every other pin doesn't wiggle. So power and ground and other 'teady' signals can occupy the 'shield' pins. 2x15 works for me too. It is quite interesting to look at the more successful buses out there. ISA comes to mind. The only real change from ISA IMHO is that fast serial now seems to cut down on pins a lot. So DMA request results in data on fast serial 'bus' instead of parallel address/data type bus and so on.

I have moved away from I2C. Driver seems too complex for what it offers. Most of our products have a half-duplex one or two wire serial port, 1200 baud. Works well even for very low cost micros. Driver is very small by normal bus interface standards. And many data sources don't need much bandwidth, but having a cheap micro to buffer the bus and to preprocess data is nice. Data rate shifting can be easily be added as well.

Right now, I would suggest that whatever connector be populated with cpu power and several ground and 'lots' of nearby pins and maybe raw power and a few user pins. As we use the board it will become clear what changes make sense.

Wiz

ADC reference - I would add an adc ref - an ultra cheap TL431 is MUCH better than the VCC.. (2.5V, SOT23-3, perfect for 10bit, 0.0xEuro).
Connected to RA10/Vref+

_________________
Pukao Hats Cleaning Services Ltd.

Changes:

* reconnected the upper data pins to the lower data pins on the SDRAM.
* removed the LDQM and UDQM lines from the PIC32 and hardwired them to ground and +3.3 volts, respectively.

Tested writing and reading a 4 meg file with dd. Failed with the usual issues.

* inserted 150 ohm resistors into the data lines between the cpu and the sdram. Connections for each data line are: PIC32 pin - resistor - SDRAM lower data pin - SDRAM upper data pin.

Tested writing an reading a 4 meg file with dd. Worked. Tested several more times. Still worked.

I'll reconnect the LDQM and UDQM lines to the PIC32 and continue testing.

Wiz: I thought of that, but placing SDRAM or MCU on different sides of board would need 4-layer board, at least. With 2-layer board, we are quite limited.
Pito is right about decoupling, that would be a problem, especially for SDRAM. 4-layer (or even more) would be beneficial for such as packed designs - aside from other benefits it allows "lighter" decoupling. I know the board looks empty, but it will be full of traces and ground planes

madscifi: resistors in DATA lines are the last thing I would expect to help. However, it seems like it can be good idea to include those resistors on board, as Pito suggested before.

Pito: yes, voltage reference could be good idea

_________________
http://jaromir.xf.cz/
https://hackaday.io/jaromir/

I've reconnected the UDQM and LDQM lines and put a filesystem on the SDRAM device. I'm using a 8Mx16 bit chip and I'm able to write 4 different (slightly less than) 4 Meg files on to the ram disk and compare them successfully against the source files, so both the upper and lower bytes are usable.

I have not tested address bit 12 as the chip on the protoboard is not that big, but it should just work (famous last words).

The driver needs more testing and some cleanup, but it is essentially functional at this point.

The fact you need resistors between the pic32 and sdram data bus might indicate there is a bug in the driver- you have left the portE direction OUT (even for a moment, ie few ns) while you read data from the sdram. Therefore, ie. in our sramc driver, we set always portE direction IN after any operation to be safe. Try to set portE to input (mind the pic32 errata - see our sramc driver) ALWAYS as default (even it would cost you more instructions).

ERRATA: I had similar symptoms with my sdramc driver last Xmas during development, but then I found out the setting the PORT direction to the INPUT does not work as expected. This errata needs to be handled in this way (rd_sramc.c, l.39):

You have to CLR portE -set all bits LOW (via LATE), then set TRISE to input, do a NOP to be safe, and then you will get the portE set to INPUT. Doing single TRISE is not enough!

Latest Errata, item 26:


BTW - using the resistors on the bus (ie between CPU and other circuitry) became famous in early 80ties in ZXSpectrum (ZX81?) as Clive used that as "full automatic passive bidirectional data bus driver" - at that time 470ohm resistors were used (CPUdata-470ohm-RAM-ULA). So whatever you did on the bus (ULA-RAM against CPU) you never got a "hard" bus collision. The bus collisions (outputs fired against outputs) were converted simply to heat

PS: in order to support the retro-style idea you may use the resistors on the data bus (as well on CLK, WE). Use a 0612 smd dip pack. I would go with 220-270ohm for data bus (2x4res pack) and 33-68ohm for the control signals (1xpack). The driver shall be checked for the errata/bug stuff as well ! It shall work w/o the data bus resistors of course (plz make a test then w/o bus resistors), adding them increases the stability/reliability even more..

In each case do use 4x 2k7 pullups (also a pack) on UDQM, LDQM, CS, WE, plz.

Colour layout c2012 Pito. All rights reserved. United Colours of RetroBSD.

_________________
Pukao Hats Cleaning Services Ltd.

Nice colors, Pito

I did a quick test of routabily of board around SDRAM. It was easier than I expected. We can have nice groundplanes under SDRAM.
Rest of the board will be piece of cake.

In the meantime, I added series resistors for some lines (data lines, CLK, CAS, RAS, WE, CLK), added diodes for power supply to allow both USB and external powering, fixed pull-ups around SD card and added voltage reference. Interesting, TL431 in SO-8 seems to be cheaper than TL431 in SOT23.
Pull-ups on SDRAM control lines to be added.

_________________
http://jaromir.xf.cz/
https://hackaday.io/jaromir/

power diodes - do we need 1A one (huge)? - 0805 schottky 300mA would be ok
do not forget pullups on udqm, ldqm, cs, we
routing around the dram is nice..

_________________
Pukao Hats Cleaning Services Ltd.

Hi Jaromir,

Very impressive. Sign me up for a bunch .

Wiz

p.s.- Which layout package are you using? Maybe I can set it up here too?

Hi again,

Can we mount 2nd SD on bottom or make some holes or pads to attach it (easily)?

Wiz

Hi Jaromir,

A couple of other comments:

1. On JP3 and JP4 usually put serial RX between VCC and gnd. To give it some shielding and also to keep glitches on TX from coupling into RX and driving it below or above ground. So my pinout is something like: 1.vcc 2. rx 3. gnd 4.tx.

2. I usually put TCK on JP2 between gnd and vcc. I have had significant problems since J-TAG stuff is frequently VERY fast. I usually include a series 100 ohm in TCK. So my pinout typically is 1.vcc 2.tck 3.gnd 4. data-in 5. data-out 6. mode select. I generally allow for 10 pins with convenient I/O pins on 7-10. This allows various piggyback stuff to be plugged into the J-TAG connector when it is not being used for J-tag. This is also because I have a lot of 10 pin 0.1inch stuff .

HTH

Wiz

Pito, the code is already structured so that the data port is normally in the input state - it is only turned to output just before the start of a write and it is changed back to input immediately after the writing phase completes.

Fascinating. I was pretty much convinced that putting the errata code in was not going to change the behavior, based on where in the writing process the direction changed (after the write completed) and the description of the failure. I was wrong. Setting the data port to all zeros before changing back to input mode appears to fix the write problem without the need for resistors in the data lines. Thanks for discovering/digging that up.