ESP32 S2 board design

[mcer12]

I am happy to design a board with ESP32-S2 but let's first take our time and discuss this thorroughly. I can't say I understand the low level stuff so it would be best if @vroland and @martinberlin step in and discuss the best pinout for the S2.

What I would like to archieve:

• Get rid of port expander
• Get rid of CH340 and use native USB (native usb could also allow for something like USB display device, maybe)
• Still have some GPIOs left for buttons / inputs

[martinberlin]

Hi @mcer12 I like the idea a lot. And I will start researching in that direction. In my opinion, if possible, would be great to find a way to supply the required voltages with an existing Board and try to send the data part/ required signals to refresh with an S2 (Would that be possible?) Because that would be great so we can check if the GPIOs we choose and the I2S DMA transfer works as expected, before investing many hours of design in something that so far no one tested. Also if this design alternative has no PCA9555 then the software has to change. Maybe it's not a bad idea to make v1 "as is" only without CH340, when my S2-WROVER boards arrive, I will try to flash them without any USB-> Serial, making just a small board with a 5 to 3.3v regulator and see how that goes. This is a very interesting idea, but it might be not as easy as it seems, also the S2 has GPIOs in the down side so I can imagine the routing of all pins will be more complicated. The problem is that I also do not understand all the low level stuff and what implications might have S2 with all details. With minor modifications it compiles that’s all I can say for now. For me, personally what it’s missing when you build a new board is a test program, that will check that the basic components work and give you more hints to what to fix. Right now the current behavior if pwr good does not come from PMIC is that stays in a waiting loop.

Got two of this cheap connectors: I will use one to get the power lines from existing V6 board, and with an S2-WROVER, both sharing GND and 3.3v I will try to send the data signals plus:

• CKH
• STH
• CKV
• LE

If that test is successful, at least we can say with a probe that works and at the same time confirm that PINs selected works as expected. And I could of course change them at will with a proven test that work. I think that could be a good idea, what do you thing Mcer?

[mickeprag]

After study the datasheet and the source code I find these pins with the following requirements:

Low speed pins (ok to use port expander)

• EP_OE
• EP_MODE
• EP_STV
• SMPS_CTRL
• CTRL+22V
• CTRL-20V
• CTRL+15V
• CTRL-15V

High speed. Used in i2s (for speed?)

• D0..D7
• CKH
• STH

Connected directly to GPIOS in current boards but seems not be time critical?

• CKV
• LE

In total 20 GPIOS needed. All digital and all outputs. 10 of then should preferably be connected to i2s.

[martinberlin]

Hi @mickeprag , I disagree partly with this. CTRL 15 /22 voltages are not pins (at least in V6 boards). If you take the 8 pins that are controlled by IO expander PCA9555 you have this extra pins apart of the 8 data-lines: TPS_PWR_GOOD (Feedback pin that get's a signal when PWR lines are ready) TPS_WAKEUP - wakeup signal for TPS651853 Pmic TPS_VCOM_CTRL - sets the voltage for VCOM and other 5 that go to the EPD display EP_CKV EP_STH EP_STV EP_MODE EP_OE EP_LE Latch enable, that I think is the signal that the row is ready to be sent

[martinberlin]

I started with this project, first with a V6 version updating S2 and doing my own board: https://github.com/martinberlin/H-S2-wrover-dev-board/tree/epd-v1#epdiy-s2-parallel-epaper-controller First goal for me is to get the voltages and data control lines correctly, so I can work on the software side. I'm afraid my V1 will probably not work, and I have to be wiser next time, making prototypes only with the needed components to try this (And not with USB / battery charge etc) This can be done in a new version once the whole thing works. But well, you fail, you learn I would say. Will keep you updated once it comes from JLPCB at the end of February and then I manage to solder TPS65185RGZT (a millimeter bigger than the one V6 uses, but limited to 150mA) And I will buy one Inkster board from @mcer12 as soon as I finish with my move to Barcelona.

[mickeprag]

Do you know what the issues are with your V1 board?

[martinberlin]

The issue is just that is the first time I send to fabrication something complex, before I just built small adapters and things alike. So this is my first real PCB design, it's actually a clon of existing V6, but with different design and the changes proposed here (No IO expander, no USB-to-serial chip, and of course S2-Wrover) The Kicad files are there if you wish to analyze it.

[mcer12]

One more thing that I just remembered... I use NTC thermistor in my boards instead of temperature sensor. They are super cheap, simple to use an most importantly it's a generic part so it's easily replacable if one vendor stops production. I also hook it up to the EPD power rail so it's only powered when the display is powered.

LCSC part number of the one I use: C95955

[martinberlin]

Thanks Mcer! Next week comes my S2 prototype and I could test if the IOs I selected to test the communication to epaper works. If it does, and you want, I can send you a PCB stencil with TPS65185RGZR soldered. But only if you want to check how it is, otherwise I spare you the distraction ;)

[mcer12]

What do you mean by PCB stencil with TPS65185RGZR soldered? :)

[martinberlin]

Sorry I meant a PCB, not a stencil (Don't know what I was thinking) Ordered 5 of this, but only 2 have SMD placing. For the rest I will solder all by hand, except the TPS65185RGZR, that will solder an expert with right equipment (Already killed a V6 board trying to repair a broken TPS65185). My father that is 65 solders much better than me!

[martinberlin]

PCBs arrived. After soldiering TPS2113 power mux and getting the expected 3.3v in S2, I proceeded to flash using DFO mode. First of all, this works only after adding an udev rule and your user to the group. Only then dfu-flash detects the device.

Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download[===========] 100%       716800 bytes

@mcer the idea is good but I’m afraid is not practical. Because then also to do Serial, you have to enter in dfu mode again (boot pressed + once hit RST) only after that lsusb lists an ESP32-S2 device. And doing monitor I catch the serial at the end, does not trigger a reset, so it’s a bit weird for debugging.

[mcer12]

There must be some automatic process for easy flashing. I need to get my hands on some S2 dev board to get my hands dirty :D

po 28. 2. 2022 v 21:50 odesílatel Martin @.***> napsal:

PCBs arrived. After soldiering TPS2113 power mux and getting the expected 3.3v in S2, I proceeded to lash using DFO mode. First of all, this works only after adding an udev rule and your user to the group. Only then dfu-flash detects the device.

Determining device status: state = dfuIDLE, status = 0

dfuIDLE, continuing

DFU mode device DFU version 0110

Device returned transfer size 64

Copying data from PC to DFU device

Download[===========] 100% 716800 bytes

@mcer https://github.com/mcer the idea is good but I’m afraid is not practical. Because then also to do Serial, you have to enter in dfu mode again (boot pressed + once hit RST) only after that lsusb lists an ESP32-S2 device. And doing monitor I catch the serial at the end, does not trigger a reset, so it’s a bit weird for debugging. [image: 8D2085C6-754B-4F2D-B62B-83339133DE64] https://user-images.githubusercontent.com/2692928/156056359-154ae4be-c3a0-4eea-b708-9982fea8db58.jpeg

— Reply to this email directly, view it on GitHub https://github.com/vroland/epdiy/issues/144#issuecomment-1054650108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIAMMAJP5JCMJRWDIDHAFXTU5PNZPANCNFSM5NDMCIGQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[martinberlin]

I think flashing is the least of the problems. The only annoyance is that you need to press BOOT and while is pressed, click on RST so it enters in DFU mode. Usb list devices does not show anything until you do this. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/dfu.html

But for me the issue is that if you are developing something, you cannot enter serial mode easily, you need to run menuconfig like described here (Or set some defines if using Platformio) and set the Console channel to CDC mode. So unless you discover something extra, just taking in account the buttons press, plus the extra dev rule (if on linux) plus the CDC configuration... Well if you use it to flash from time to time, and you design something that really needs to be smaller without space for CH340 then it makes sense. But if not, all this steps to flash the device, and still get uneasy access to serial (DFU mode does NOT send a reset signal like normal monitor mode) then it's a no-go for me. But you have to really try it for yourself and see if there is any better and faster way to improve what I describe.

[martinberlin]

Yesterday advanced a bit with my implementation of the S2 board. Now the voltages seem to be stable and if the software side worked in this MCU I think the pixels could be pushed and get a refresh. Still stuck with this: Thermistor °C: 27 Waiting for PWRGOOD to turn HIGH... TPS_PWRGOOD ok

`Guru` Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x4001abc8  PS      : 0x00060030  A0      : 0x8008600e  A1      : 0x3ffc7530  
A2      : 0x00000000  A3      : 0x3ffc7540  A4      : 0x00000100  A5      : 0x00000000  
A6      : 0x55555555  A7      : 0x55555555  A8      : 0x3ffc7640  A9      : 0x3ffc7500  
A10     : 0x00000000  A11     : 0x00001000  A12     : 0x00000001  A13     : 0x000013b7  
A14     : 0x00000001  A15     : 0x00000000  SAR     : 0x0000000e  EXCCAUSE: 0x0000001d  
EXCVADDR: 0x00000000  LBEG    : 0x00000001  LEND    : 0x000013b7  LCOUNT  : 0x40026895  
0x40026895: _xt_user_exc at /home/martin/esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:633

Backtrace:0x4001abc5:0x3ffc75300x4008600b:0x3ffc7540 0x40086093:0x3ffc7680 0x400860da:0x3ffc76b0 0x40085e9e:0x3ffc76e0 0x4008704c:0x3ffc7710 0x40085e2d:0x3ffc7730 0x40085e82:0x3ffc7760 0x4009769e:0x3ffc7780 0x4002db6d:0x3ffc77a0 
0x4008600b: epd_push_pixels at /home/martin/esp/projects/epdiy-rotation/src/epd_driver/render.c:67   -->
memcpy(epd_get_current_buffer(), row, EPD_LINE_BYTES);

It seems this line is hanging on the S2 exactly when it's trying to push the row to the buffer (That is sent using DMA by I2S LCD transmission mode in 8-bit parallel) Maybe there is something in the I2S instantiation that needs to be corrected. But I'm quite lost there...

@markbirss replied in epdiy.slack.com

LoadProhibited, StoreProhibited These CPU exceptions happen when an application attempts to read from or write to an invalid memory location. The address which has been written/read is found in the EXCVADDR register in the register dump. If this address is zero, it usually means that the application has attempted to dereference a NULL pointer. If this address is close to zero, it usually means that the application has attempted to access a member of a structure, but the pointer to the structure is NULL. If this address is something else (garbage value, not in 0x3fxxxxxx - 0x6xxxxxxx range), it likely means that the pointer used to access the data is either not initialized or has been corrupted.

[martinberlin]

LoadProhibited, StoreProhibited These CPU exceptions

Fixed this one. I2S instantiation was crap. Now getting the right *pointers (Check last commit) Very close to getting it to work @mcer12

[mcer12]

Thats awesome, looking forward to it!

st 18. 5. 2022 v 12:52 odesílatel Martin @.***> napsal:

LoadProhibited, StoreProhibited These CPU exceptions

Fixed this one. I2S instantiation was crap. Now getting the right *pointers (Check last commit) Very close to getting it to work @mcer12 https://github.com/mcer12

— Reply to this email directly, view it on GitHub https://github.com/vroland/epdiy/issues/144#issuecomment-1129860865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIAMMAKSQUE7YRVQBMBO5YLVKTDVVANCNFSM5NDMCIGQ . You are receiving this because you were mentioned.Message ID: @.***>

[putyn]

any update on this topic ? I am too looking to design my own board based on the latest v6 also with some inspiration form @mcer12's design

[markbirss]

@putyn I have sent you a Slack invite

[martinberlin]

any update on this topic ?

Not yet because I've been busy with client work and my rent is higher in Barcelona so I have less time for fun. There are some issues with S2, primarily because I've choose wrong PINs, will come back to that later. But also the single I2S that is on board behaves different. I think the best take would be not to go with S2. Since it's going to be a lot research time to end up with a chip that is anyways NRND "Not recommended for new designs" Is a nice exercise but not to make a new PCB. IMHO @mcer12 Let's close this and try to go for a S3 sending the data using the new LCD component just as is done in Lovyan GFX library

My thinking here after loosing many hours and about 200€ invested in making 2 failed PCBs is to start a completely new design with an ESP32S3 that we can put on top and from that on figure out Routing and correct GPIOS (Don't regret since I learnt a lot for future designs) Designing kind of Breadboard v1.0 PCB where you can switch pins until you find the right combination. Because it's just false to think you can use any PIN for certain signals, something that costed me a lot of time to learn.

[mcer12]

@martinberlin agreed!

[lanistor]

@martinberlin Agree to use S3. We tried to retrofit to S2 or S3 some time ago because of insufficient pin count. However, the S2 module issued by Espressif can only support up to 2M of PSRAM, which in many cases cannot meet the memory required for screen rendering, especially if you use a UI library such as lvgl. However, adding PSRAM is not currently in Espressif's plan. If it is developed by ourself, there will be a lot of development and debugging workload.

[martinberlin]

Thanks for the feedback. Closing here then let's open another S3 issue to plan this when we figure out how to do it. I suggest making a design where we can just insert an existing Espressif S3 Dev. board so we just need to add the high voltage circuit. No battery charging....Anything except the TPS65185 to generate voltages. Then we can just play around leaving some handy Jumpers for signals in case we need to route it differently. Otherwise you need to make many versions until you get it working and that is not cheap.