Epdiy S3 board discussion

[mcer12]

Since @vroland resumed work on the S3 board, let's throw ideas and notes about the schematic first, then the pcb layout and features. Don't discuss this on slack because the conversation will get lost!

[Yardie-]

Here are some of my coments from todays discusson on Slack Regarding Why we still have the IO expander in the design.

pins 35 36 and 37 cant be used on the R8 Octal PSRAM S3 also to get the voltage over the ADC you need a pin. so with 16 data lines there is not much left 5:10 You could add an ADC expander or an I2C voltage gauge which would allow it though. 5:11 I have built a board with them all connected but it is only 8 data lines 5:12 Also I mucked up and it will only work with an R2 Quad PSRAM S3 (ie I used the naughty pins) 5:13 I'm just waiting for some S3R2 modules to arrive so I can test

I like the idea of doing away with the port expander however it becomes a choice of 8bit screens or 2MB PSRAM

If you only used a Quad PSRAM S3 (2MB) you could squeeze a 16 bit on though. You would just have to do everything else over Serial or I2C

[mickeprag]

One idea is to make two boards. For 8 bit displays we can skip the portexpander and another board for 16 bit displays with a portexpander.

[Yardie-]

With the S3 you can also skip the Serial to USB. I have built many boards that program seemlessly directly over USB via the CDC interface. With no specific setup changes and no need for the Vulcan grip of death either. However I can see the point of keeping it for as Valetin said the other day "having the external uart could be valuable, if you want to connect a keyboard or something"

[mcer12]

My notes about the schematic:

1. USB to Serial - use CH340C, simple to use, nice (but will need a second regulator to switch power)
2. MCP1700 - even though it works, it's not a suitable regulator for this purpose. RT9080 is pretty much perfect with great transient response and should deal with transmission spikes hopefully just with the small ceramic capacitors.
3. TP4057 instead of TP4056 to save some space
4. add 34pin and 33pin connectors for 6" XC6/XD4 displays and 9.7" displays respectively

[mickeprag]

A note on 1, the CH340C can work without a secondary regulator.

[mcer12]

@mickeprag it can but it will be 5V logic which may or may not work. Maybe it will but as opposed to ESP8266 I don't think ESP32 is 5V tolerant. Datasheet says absolute maximum 3.6V and who am I to question espressif datasheet :)

[martinberlin]

Hi there, I've been busy so didn't had time to do much in latest weeks. I'm fighting hard to integrate (And make some money to pay bills) in Barcelona. First of all amazing that @vroland is working on V7 that is something great since finally it will be possible to have a new PCB and hopefully also a simpler controller, I mean now that LCD module in S3 will do most of the transmitting parallel data. One thing I would like to propose Valentin is to add a new Discussions area to this repository, that is easily doable just activating a checkbox in settings, and then we could discuss there without creating a new Issue.

Not that it bothers me, more on the contrary, I'm happy to collaborate in any discussion. But then having this area we could also move Issues that are not real bugs or enhancements to that area, having a clearer focus and less Issues.

Onto the discussion now:

• Serial chip: Even though everybody says for the new S3 you don't need a USB to UART chip, not everybody got it working as is, and for me at least it did not work out all of the time. UART programming is also more than just having Serial to program, it also toggles DTR / RTS that put the MCU in the right mode to program. If it would be my opinion to choose I disagree completely in removing UART.

I use CP2102 that is too big and there are smaller things for the task. Espressif official boards also have UART and an UART chip in place so I see no reason to save space and then have additional problems in the most basic thing that is flashing the Firmware. But that is only my opinion about it.

What it would be very nice to achieve for me is to have 16 datalines support so we can try new models (V5, Inkster & V6 all give support to all existing models) My desire for this project will be always to innovate and support whenever possible new models so we don't need to buy expensive and complicated controllers, we can just keep on using EPDiy as a rock solid project for all parallel projects. But I agree would be nice to have a PCB that offers also 33 and 34 pin connectors plus a 40 pin FPC connector. And everyone decides what will be soldered where. But of course that is quite a challenge to make in quite a reduced space. I see also Micke point of having an IO expander if after 16 data-lines plus other control-lines there is just a few available GPIOs to do something custom. Maybe what it could be done also is to add a Groove connector (4 pin) with I2C. So everyone can expand the PCB with anything I2C, like a port expander, or any I2C sensor / Touch whatever that is driven by this protocol. I hope Valentin soon will share the Schematics in SLACK or here and everyone can see better where is V7 board going.

[Yardie-]

I only use CDC to program my S3 and C3 units and only have a problem when there is a bad solder joint. I do use esp-idf on linux though. Itcould be different for different OS and tool-chains though.

I only have to use the boot switches when I have a locked system.

One thing I do do and maybe it is worth adding to the design is

• add 0 ohmn resistor in line on the D+ and D- lines this is in the S3 design guidelines so maybe that helps. They do explain it in the guide.

[mcer12]

@Yardie- can you share the document?

[vdp]

Does anyone have experience and/or opinion on using MAX17135 vs TPS651851? Glancing through the datasheet it seems roughly analogous to TI's IC, but slightly simplified. Could be easier to solder, because although it's still 6mm package it has only 32 pins and the pitch is the same as for TPS65185RGZ(the 7 mm package) and, from experience, for novice solderers that could make a lot of difference. In my experience TPS651851 is also rather fragile and easy to damage when soldering.

[mcer12]

The issue here, first and foremost is the availability. TPS65185 is widely available, sometimes expensive yes, but available. MAX17135 not so much, especially on lcsc which most of us use for pcbs and assembly. Novice solderer shouldn't solder QFN package but start with something simple :D

[mcer12]

@Yardie- I have to say I have an S3 devkit at home with native USB broken out but I didn't test it yet :D I'll try to get to it over the weekend, see how difficult it is to work with it and if it's easy to set up, we can make some kind of easy guide and ditch the CH340, I'm all for it. For development tho, having the external chip for serial communication with autoreset is awesome. If it's more than just pushing a button to put it in flash mode, I'm not going to like it very much :D

[Yardie-]

Just heading out for the weekend but I will find the section about the 0ohmn resistors. CDC programing as I have tried to explain needs no buttons or special configuration . It just works. Resets into flash mode and uploads the code then restarts the S3 or C3. Many of my C3 PCBs had no buttons at all. They like the S3 just program and spit any printf statements out over USB. You don't include serial or anything.

The S3 doesn't even have the glitch of not restarting when you upload like that.

Anyway have a great weekend everyone I'm off.

[Yardie-]

Ok @mcer12
Here is the document https://www.espressif.com/sites/default/files/documentation/esp32-s3_hardware_design_guidelines_en.pdf On page 16 it states

2.9 USB
ESP32-S3 has a full-speed USB On-The-Go (OTG) peripheral with integrated transceivers. The USB peripheral is
compliant with the USB 2.0 specification. GPIO19 and GPIO20 can be used as D- and D + of USB respectively.
It is recommended to populate zero-ohm series resistors between the mentioned pins and the USB connector.
Also reserve a footprint for a capacitor to ground on each trace.
ESP32-S3 also integrates a USB Serial/JTAG controller that supports USB 2.0 full-speed

At one stage they recommended 22pF capacitors on these two lines as well. I did that and it was totally wrong and USB did not work. After removing the capacitors everything works fine so I no longer add these to my designs.

However I also just noticed that these resistors are not included in the DevKit design. So maybe they are not necessary. I will still add them as This is one area I have absolutely no problems with.

I also recall they had issues with USBC to USBC connectors in as much as the Chip will only handle USB2 and the system was trying to use USB3 over USBC. The solution they came up with at the time was to USB a USB2 Hub but I find it easier to just add micro USB connectors to the PCB.

[vroland]

Sorry for the silence, I was sick for a week and then busy with chistmas... Here's a new version of the schematic though ;) So far, I've addressed the following points:

• Added the 33 and 34 pin connectors. Let's see what sticks when it comes to designing the PCB.
• Swapped the CP2102 for the 340C. After reading the discussion I'm not entirely convinced CDC is as reliable for programming and resetting as the UART version, which is known to work reliably. Also, I'd like to experiment with using a board as a USB host at some point, e.g. reading USB keyboards and the like, so I prefer to have the dedicated USB host free.
• Changed the MCP1700 for the RT9080, which seems more available and has slightly better characteristics.
• RTC crystal has two 12pF caps. Feedback is welcome :) epaper-breakout.pdf

[vroland]

@mcer12 You recommended the TP4057 over the TP4056, but the only datasheet I can find is in chinese, so are there any differences aside from the footprint?

[mcer12]

@vroland lower maximum charge current (600mA instead of 1A) due to smaller package size. TP4054 can be used but has only CHRG led, not DONE led so it just looks off when fully charged nad I don't like that.

[Yardie-]

@vroland you might want to consider treating pins 35 36 and 37 as NC. The new 2 series S3 only have Octal PSRAM according to https://www.espressif.com/sites/default/files/documentation/esp32-s3-wroom-2_datasheet_en.pdf

[vroland]

@mcer12 If the only difference is package size, why not stick with the 4056 to allow higher charging currents? It really doesn't save that much space. @Yardie- Right now, the pins are just broken out, so effectively NC. But I could add a warning on the silkscreen to not use them unless you want to compromise on speed.

[Yardie-]

Yeah I think a warning is a good call as it is not obvious to new users of the S3. And the 2 series will take while to come online mainstream.

[mcer12]

@vroland sure no problem, I was under impression there's size constraints since you wanted to remove some connectors, that's why I suggested it. TP4056 is more generic part so it's better usually.

[mcer12]

@vroland I was checking out the schematic again and I see GPIO0 is not used for anything and could free up some other more useful pin.

[Yardie-]

GPIO0 is boot on the S3

[mcer12]

@Yardie- You mean like on all other ESP modules? :) It can be used unless you pull it low during boot, so for driving high impedance inputs it's perfectly fine. Epdiy V5 uses GPIO0 btw.

[vroland]

The board will be biggern than the V6 board anyway, so I'll just make it wide enough to fit everything comfortably this time :) @mcer12 Good catch, I should absolutely use GPIO0 for something else. I'll have a look what goes well with the layout, probably some clock or enable signal.

[PickaxeHit]

there is a question that esp32-s3 doesn't have parallel I2S support. It must use LCD peripheral or Octal SPI to drive the panel.

[Yardie-]

@PickaxeHit that's what the S3 code @vroland is working on is all about. This is not a simple thing and will take some time. He is also working towards 16 bit parallel displays in the same code. It is pretty much the point of this thread to make the current information/discussion available publicly.

[Yardie-]

Yes @mcer12 I use it regularly fair point to break it out or use it.

[martinberlin]

I wanted to comment about this point:

USB to Serial - use CH340C

CH340 has issues with all latest Ubuntu versions. You just cant flash any MCU with this chip unless you know how to fix it.There is a Braille reader associated directly with CH340.

In case that happens and you don't use a braille display this should do the trick:

sudo apt remove brltty

[lanistor]

@martinberlin @vroland Hi, is S3 board usable now? which branch can i use it?

[martinberlin]

Hi Lanistor, there is a branch called s3_lcd. @vroland has to confirm when it's ready. It might have some modifications pending. Please do not send anything to production until Valentin gives the green flag

[lanistor]

Hi Lanistor, there is a branch called s3_lcd. @vroland has to confirm when it's ready. It might have some modifications pending. Please do not send anything to production until Valentin gives the green flag

Thanks a lot. @martinberlin @vroland Is there a list to show the problems need to resolve? we prepare to use it to production after 4 months, and we are wondering if we can use it, if ok, we should test it from now.

[vroland]

@lanistor The tracking pr is #251. I think the hardware should be mostly solid now, there is just a lot of software work to do, which is currently constrained by my time...

[lanistor]

@lanistor The tracking pr is #251. I think the hardware should be mostly solid now, there is just a lot of software work to do, which is currently constrained by my time...

Thanks for reply. It's really a great job.

[lanistor]

@vroland @martinberlin The computer cannot recognize and read the s3 board. After plugging in the data cable, the green light is on, but the board cannot be recognized by the command ls /dev/tty.*. The driver of CH340 has been installed, and there is no problem with the recognition and flash of the v5 board. Does the s3 board need to install a new driver?

[martinberlin]

The driver of CH340 has been installed, and there is no problem with the recognition and flash of the v5 board. Does the s3 board need to install a new driver?

Not really. Are you sure that you updated your branch before sending this to fabrication? send a bit more details please and check that the USB to UART wiring is correct

[lanistor]

The driver of CH340 has been installed, and there is no problem with the recognition and flash of the v5 board. Does the s3 board need to install a new driver?

Not really. Are you sure that you updated your branch before sending this to fabrication? send a bit more details please and check that the USB to UART wiring is correct

I am using the design in the code 2 months ago, is there a problem with the previous PCB design?

[martinberlin]

If you didn't use last update called "v7 hardware fixes" https://github.com/vroland/epdiy/pull/251/commits (Scroll down commit 30ed99b4aae2695df2c928ec879f4a50866ec0a7 )

Then yes it's a problem since D- D+ where swapped. Please check because there where also some other minor corrections. Check in this image initial prototype by VRoland. I sent one PCB with this corrections to him by post but it has no ESP32S3 soldered so we need to wait and confirm that everything is working as expected.

This release was actually a work in progress so we need to be patient to check that most issues are fixed or risk an early production where it can be that things still need minor corrections.

[mcer12]

@martinberlin I'm sorry to be that guy but untested boards shouldn’t be on github or at least properly labeled as untested ;)

[martinberlin]

Well this is still in a Pull-Request that is not merged and hence a clear Work in progress. I've been always loud and clear to wait until a confirmation from @vroland that the PCB part is ready to send release 1.0 to fabrication.

The tracking pr is https://github.com/vroland/epdiy/pull/251. I think the hardware should be mostly solid now, there is just a lot of software work to do, which is currently constrained by my time...

When Vroland made this comment he just updated the PCB Hardware part. Now if you don't pull the updates and check everything considering is a very early release, well then it's not his fault.

[mcer12]

@martinberlin Sorry I was under impression it’s already merged…

[lanistor]

If you didn't use last update called "v7 hardware fixes" https://github.com/vroland/epdiy/pull/251/commits (Scroll down commit 30ed99b )

Then yes it's a problem since D- D+ where swapped. Please check because there where also some other minor corrections. Check in this image initial prototype by VRoland. I sent one PCB with this corrections to him by post but it has no ESP32S3 soldered so we need to wait and confirm that everything is working as expected.

This release was actually a work in progress so we need to be patient to check that most issues are fixed or risk an early production where it can be that things still need minor corrections.

Thanks a lot, i'm making the new boards.

[martinberlin]

@lanistor please do not trash the ones you already mounted. Maybe some other people can try if you don’t have the time to fix them and you can offer them in the EPDiy Slack group

[lanistor]

@lanistor please do not trash the ones you already mounted. Maybe some other people can try if you don’t have the time to fix them and you can offer them in the EPDiy Slack group

I can't use my computer to connect to the boards I made last time, so I don't know how to fix them.

[martinberlin]

Just try to fix it inverting the USB to UART cables. Make sure also to check that GBR files and drill files are in the latest stand before sending it to fabrication. In any case just open the V7 in KiCad and regenerate them just in case. Please always check that you are in the right branch and in the latest stand before sending anything to production.

[lanistor]

Just try to fix it inverting the USB to UART cables. Make sure also to check that GBR files and drill files are in the latest stand before sending it to fabrication. In any case just open the V7 in KiCad and regenerate them just in case. Please always check that you are in the right branch and in the latest stand before sending anything to production.

Sorry, I'm not a PCB designer and don't know how to use KiCad. I sees the latest commit has changes of gerbers, so the gerbers should be updated already?

[martinberlin]

@vroland I just opened latest s3_lcd v7 hardware and I think that Drill files are not updated. At least opening this in KiCad settings I see some difference:

modified:   epaper-breakout-NPTH.drl
modified:   epaper-breakout-PTH.drl

But I'm not 100% sure since I'm using version 7 and this was done with v6 of KiCad so maybe is just that. If this is like this can you please update it so people trying to send this to fabrication do not miss latest updates?

Sorry, I'm not a PCB designer and don't know how to use KiCad.

Sorry @lanistor but this is open source hardware and you are risking here sending to fabrication something that is still not merged. I'm also not a PCB designer but I forced myself to learn KiCad and at least understand how this is exported to Gerbers. I highly recommend you to follow the same path. Sending something to fabrication without this knowledge has a high risk of failure, since even if you trust the source, this is open source and we all can make mistakes or forget to update something, etc. In the top of that maybe you want to add a custom message or URL in the Silkscreen or any indication so I highly recommend to learn a bit how is the process.

[lanistor]

@martinberlin Thanks, i create new gerbers and made new boards.

But i got an error when start the board, here is the error log:

E (302) quad_psram: PSRAM ID read error: 0x00ffffff, PSRAM chip not found or not supported, or wrong PSRAM line mode
E (306) cpu_start: Failed to init external RAM!

[martinberlin]

Hi @lanistor can you please post a close up photo of the MCU? Sounds strange this error, did you configured PSRAM using menuconfig? Please check the epdiy wiki page where I'm starting to document stuff and hopefully will soon migrate the docs in readthedocs.

Make sure you enable PSRAM (Octal for this board)

Component config --> ESP PSRAM --> Enable SPI-connected RAM --> Config --> QUAD/OCT

Additionally:

• Set SPI RAM clock speed to 80MHz
• Make sure you are using IDF version 5. Open a console and try doing a: idf.py --version

[martinberlin]

Hello @vroland compiling last s3_lcd I'm getting this error:

src/epd_driver/display_ops.c:61: undefined reference to `i2s_deinit'

If I see this correctly that file is missing an include: #include "render_method.h" which defines RENDER_METHOD_LCD and then this i2s_denit is excluded. I will be testing different things on each update to make sure there are no errors building different examples. Will need to correct also my www-image download jpg demos since after IDF v 5 there are a lot of mistakes if you don't cast (int) in the Logging functions (It says to include in console to fix it, but it really does not)

V7 is working great for me to drive 16 bit epaper displays but trying with smaller 8 bit displays like ED060XC3 I'm having issues. Not drawing a single full framebuffer screen like the dragon example, that runs fine. But running the demo using latest code on s3_lcd I get this:

assert failed: retrieve_line_isr render_lcd.c:43 (lq_read(lq, buf) == 0)

Backtrace: 0x4037651a:0x3fc9d850 0x40380df5:0x3fc9d870 0x40388181:0x3fc9d890 0x40378769:0x3fc9d9b0 0x40378971:0x3fc9d9d0 0x403789b9:0x3fc9d9f0 0x4037b44d:0x3fc9da10 0x40377bc5:0x3fc9da40 0x4003c608:0x3fcb2b80 |<-CORRUPTED

My LCD config looks like this:

    LcdEpdConfig_t config = {
        .pixel_clock = 10 * 1000 * 1000,
        .ckv_high_time = 60,
        .line_front_porch = 4,
        .le_high_time = 4,
        .bus_width = 8,
        .bus = lcd_config,
    };
    epd_lcd_init(&config);