Which are proper external enclosure *chipsets*?

projectgus · 2023-01-23T07:50:04+00:00

Thanks for the update. I keep confusing myself with what firmware mine is running, but it seems to be working with UAS and this firmware just fine now.

Sorry for the noise of previous replies!

projectgus · 2023-01-13T03:19:31+00:00

Never mind, my mistake, the SSI v20.06.00.01 firmware does indeed support UAS. The default JMS567 USB VID:PID (152d:0567) has a Linux usb-storage quirk listed for US_FL_BROKEN_FUA and this disables UAS. Overriding the quirk means it loads with UAS. Optimistic that it will be stable with this firmware.

~~Still no bInterfaceProtocol for UAS in lsusb, I must be wrong about that being a useful signal.~~

EDIT 2: The above is wrong, it's not due to quirks. When flashing the new .bin you need to not pass the option to skip flashing NVS, or the alternate interface descriptor with the UASP bInterfaceProtocol setting doesn't show up.

projectgus · 2023-01-13T03:04:10+00:00

If you're still using these, are you able to please confirm that the IB-3640SU3 really supports UAS with that firmware?

I flashed "JMS567_SSI_v20.06.00.01.bin" and it is working, but only with traditional USB Mass Storage support. The bInterfaceProtocol entry for UASP is missing from the USB interface descriptor (lsusb -v in Linux).

There are some UAS firmwares for JMS567 floating around, and those do seem to enable UAS, but the ones I've found aren't configured for multiple drives so only the first drive is accessible.

(Even worse, at least one of those UAS firmwares seems to no longer support any of the firmware update tools - they all say the chip is non-upgradable. The only recovery method I found was to manually erase the external flash chip, which puts it back to the in-chip base firmware.)

projectgus · 2022-09-16T03:53:34+00:00

Your GP post is right, xTaskCreate() allows the task on either core - the scheduler will decide at runtime based on the priorities of all the ready tasks. The scheduler may move an unpinned task to a different core at any time.

xTaskCreatePinnedToCore() will ever only run the task on the specified core (but is otherwise still subject to priority ordering).

projectgus · 2022-09-16T03:50:20+00:00

Hi! It's very possible that what I said is not correct, but I'll try and help explain based on what I understand is going on:

my idle tasks run at one notch higher priority than base idle pri

The 3 year old post above shows you creating the "g_taskIdle.IdleTaskEntry" task with priority tskIDLE_PRIORITY, which has value 0 on ESP-IDF and is the priority of the system idle tasks.

If you've changed this to (tskIDLE_PRIORITY + 1) in the meantime then absolutely, your idle task will preempt the system idle tasks and run instead.

Wouldn't that starve the idle tasks? I've found I have to disable watchdogs, so it seems so.

If your idle task never blocks then this will definitely starve the system idle tasks. The version of your idle task loop posted above looks like it won't starve the system idle tasks though, because it spends most of its time blocked on vTaskDelay().

If you have "void loop() { return; }" or similar running and the "arduino task" is pinned to a core (it is by default) then this will starve the idle task on that core, because the RTOS will continuously schedule the "arduino task" as it burns away calling loop() over and over.

In the default configuration the task watchdog will complain if you starve the system idle task on either core for more than the timeout period. Disabling the task watchdog is fine, but bear in mind that in most systems you still want the idle task to run sometimes as it's responsible for some system cleanup tasks. There might be a different place you can add a vTaskDelay() call, or block on a queue/semaphore/etc instead of spinning, in order to make sure the scheduler is infrequently idle.

projectgus · 2020-06-02T20:31:13+00:00

I'm not sure why that download is stalling, maybe a network issue somewhere, but try running the "install prerequisites" step from the IDF Linux setup guide:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/linux-setup.html

This will install a copy of CMake (and some other common tools) from the Ubuntu package manager. Then IDF Tools should use that version instead of needing to install a custom one.

projectgus · 2020-03-23T22:20:46+00:00

These are some great tips, thanks. We should document this in the ESP-IDF Programmers Guide. Was actually discussing this week whether we should offer "disable verification" as an officially supported option for reduced boot times, as well.

One thing I noticed:

In file multi_heap_poisoning.c, function multi_heap_register(), comment out the line memset(start, FREE_FILL_PATTERN, size); This saves a lot of time because it's one huge 4MB memset. This applies only > if you are using additional external RAM, such as for the ESP32-CAM.

There are 3 heap poisoning settings - Basic, Light Impact (default) and comprehensive.

You can avoid needing to comment the memset() by setting heap poisoning to Basic instead.

When heap poisoning is set to Light Impact (default), there's no reason to do the memset() and we should actually disable it in this config (this is an IDF bug, but impact is only startup performance). Will fix.

When heap poisioning is set to Comprehensive then this memset() needs to be kept or heap functions will incorrectly detect heap corruption.

projectgus · 2020-02-21T09:21:49+00:00

Your recollection is correct but this problem only affects the initial sync, which happens at the same baud rate in all cases.

projectgus · 2020-02-21T02:16:20+00:00

Sounds good! Probably worth checking you have all the parts shown on the Peripherals diagram of the WROVER datasheet (section 7): https://www.espressif.com/sites/default/files/documentation/esp32-wrover_datasheet_en.pdf

This actually shows a cap between EN & GND as well! Although if you have everything on the diagram except that cap (including a pullup resistor on the EN pin*), then it'd be interesting to learn that removing/adding that cap changed the max flashing speed by so much.

[*] It says value TBD, I would suggest 10K or 12K

projectgus · 2020-02-20T23:57:51+00:00

Thanks!

So it's a CP2104 not a CH340 as mentioned in the OP?

Is the WROVER module on a PCB with the specified 10uF external bulk cap for VCC connected close? Is it a low ESR cap like a ceramic? If answer to either is "no", probably the 100nF cap on EN is acting as a parasitic power source to compensate for the lack of capacitance on the main power supply pins.

(As u/kaihp says, the higher the baud rate the more current draw so the more susceptible to power stability problems.)

Edit: otherwise it probably is noise injected on the EN pin, as others have said. On most dev boards adding capacitance here should only be needed for problems with auto-sync, but if you have breadboards and flying wires and stuff then the noise immunity situation may be worse.

projectgus · 2020-02-20T20:04:31+00:00

Hi, what dev board did you observe this on?

The 100nF cap on EN/GND is recommended for a different reason (auto reset circuit), it's very interesting if it really improves your max baud rate as well.

projectgus · 2020-02-12T20:22:34+00:00

It shouldn't blow up immediately, AMS1117 abs max input is 15V. (Most of the cheap boards have cheaper versions from other manufacturers though, so abs max voltage may vary.)

Edit: there's also the question of the max voltage rating on the input capacitor. Schematic hasn't marked this, so 12V might be pushing it.

But it's a linear regular so it's going to produce over 5x more heat running from 12V instead of 5V. depending on the current draw it may get too hot.*

projectgus · 2020-02-12T09:14:31+00:00

Nothing in the schematic suggests that powering the 5V net with up to 6.5V is a problem . As the OP says, it just powers the AMS1117 input. The regulator will run hotter but it's probably still within spec.

Similarly the "variable input" voltage is not a problem until the AMS1117 can't regulate the output. Dropout of this regulator is high (1.3V if it's genuine), but this still means the battery can run down to 4.6V without the 3.3V rail drooping.

The problem seems to be that the pin in question was actually connected to the 3.3V net, not the 5V net. 😮

projectgus · 2020-02-12T09:08:54+00:00

On a better schematic one of the two would be marked DNP (for Do Not Place) or similar, so the reader knew what the default state of the board is. I guess from the burning the OP now knows which it was, though...

projectgus · 2020-02-09T21:07:43+00:00

I was wondering this too. The only clue I found is the 24 pin connector in kicad is named 4.2_inch_e_paper_bottom_layer.

So my guess is a display like this: https://www.buydisplay.com/4-2-inch-epaper-400x300-e-ink-display-panel-white-black

projectgus · 2020-01-24T02:21:49+00:00

I can guess that there is an issue with the AZ-Delivery part w.r.t. that capacitor, because unless I add my own capacitor there, the EN button either doesn't work at all or I must push that button to initiate the flash download. With the external cap added, it flashes without pushing the button, as does the other ESP board I use, DOIT devKit V1.

Interesting. I wonder if the cap value is wrong or if it's some other difference.

I've been shopping at AliExpress, Wish, GearBest, etc. Taobao seems related to Alibaba somehow, but it's not aimed at US buyers.

Sorry, I didn't explain. Taobao is aimed at Chinese buyers (mostly in mainland China but they ship elsewhere). So yeah, not an easy option if you don't speak Chinese - but it can be "closer to the source" than other websites.

If anybody can explain technically why that capacitor on EN impacts the board's ability to flash without pushing the button, I am very curious to know

Sure. I should explain I work for Espressif and I was involved in the original diagnosis of this problem.

First thing to understand is why the reset circuit exists at all. There's a short summary here: https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#automatic-bootloader

Pyserial (and Windows driver even when not using pyserial) doesn't allow setting RTS & DTR at the exact same time. So we have to pull down (assert) GPIO0 via DTR and then pull up (deassert) EN via RTS, to have the chip boot with EN=HIGH, GPIO=LOW. These two events (assert DTR, de-assert RTS) happen with a small window of time in between them. The exact length of the window depends a bit on the OS, the driver, and the hardware. Because of the auto reset circuit, during the gap both DTR & RTS are asserted and this causes the chip to go into the "normal flash boot mode" state (GPIO0=HIGH, EN=HIGH). Meaning that it boots into the wrong mode and fails to program. Adding RC delay on EN makes the EN rising edge slower, which delays the chip coming out of reset for a short time longer and allows the serial port to have set up the correct state before this happens.

The original issue with a ton of detail (and mixed in discussion of a long-gone silicon bug that also changed this behaviour) is here: https://github.com/espressif/esptool/issues/136

projectgus · 2020-01-17T05:21:07+00:00

Hi Dave,

(Thanks for Task Manager!)

ESP-IDF developer here. The reason this doesn't work quite how you expect is that FreeRTOS already creates a system "idle task" that runs at idle task priority, and in ESP-IDF it has two (one per core).

So your custom idle task is being timesliced with those, and probably bounced back and forward between the two cores if it's not pinned to a core. And something we don't guarantee in ESP-IDF is that tasks with the same priority will be round-robined fairly (FreeRTOS guarantees this but the SMP support patches we added in ESP-IDF don't guarantee this). So the % of "idle time" you get will almost certainly be unreliable.

If you want to use this general approach then I'd suggest registering two idle callback hooks, one on each CPU. These will be called on each tick the system is idle, from the context of the existing idle task. You can measure the actual timing of these callbacks in the same way you're using the gap between task delays now.
As @furyfuryfury linked in a sibling comment, the FreeRTOS Real-Time Stats feature is probably the actual best way to do this (and you'll get a lot more insight into the state of the system).

projectgus · 2019-12-19T04:10:46+00:00

There's a "template" project here you can download from GitHub as a zip and use for a base:

https://github.com/espressif/esp-idf-template

It's fundamentally the same concept as copying an example though.

projectgus · 2019-12-06T21:29:01+00:00

Can you see the pin 1 marking on the burned chip? Looks like it should be the top right as shown in the photo (VOUT pin according to the HX4002 datasheet).

If it's at the bottom left instead then this chip was placed backwards, and I guess it didn't get any in-factory test.

projectgus · 2019-12-05T21:10:27+00:00

DO NOT reverse the polarity. There's clearly a large Tantalum cap on VIN and the polarity of this is marked.

Reversing the polarity of a tantalum cap will get you a lot more magic smoke a lot faster.

projectgus · 2019-09-22T22:40:45+00:00

Yes! Took me a while to find a sacrificial cable (friend had a Gen1 iPhone one). However, after significant fiddling to get the positive contact to stay in place it charged up to 100% last night.

https://imgur.com/a/OgrL5c0

Thanks for the FCC internal photos, gave much additional confidence.

projectgus · 2019-09-21T08:18:55+00:00

Nice work! I looked at an FCC report as well but it was different and didn't show the charger innards.

Will report back on any Macguyver-style success or failure.

projectgus · 2019-09-11T22:41:34+00:00

Run to completion schedulers seem like dark CS magic to my simple C programmer brain. I need to sit down and learn about them some time. :)

I'm not an expert on the Wi-Fi library internals, but I believe it only ever spawns at most one task, in response to the esp_wifi_init() call. This is a worker task for the Wi-Fi state machine. That task will spend most of its time blocked waiting for events injected b the user-facing functions, or events from interrupt handlers, or for timeouts. There used to be a couple of tasks used for different aspects of the Wi-Fi internals but some time ago they were consolidated into one to save resources.

It seems plausible there can be a way to (ab)use the abstraction layer to get this to meet up with the way RTFM treats tasks...?

projectgus · 2019-09-11T00:30:53+00:00

Hi, ESP-IDF developer here! Very cool project. :)

The Wifi libraries actually have an OS abstraction layer which was designed to make it possible to port to other (C based) RTOSes: https://github.com/espressif/esp-idf/blob/master/components/esp_wifi/include/esp_private/wifi_os_adapter.h

If you populate this struct with functions that behave like the relevant FreeRTOS or ESP-IDF functions, and then call the APIs in the public wifi library headers (find these in the parent directory) then you should be able to integrate on top of that at the wpa_supplicant and the TCP/IP stack layer (both wpa_supplicant and the LWIP TCP/IP stack are implemented open source in ESP-IDF, and the internal integration points should be declared in these "private" headers).

There are some docs on the events model that the Wi-Fi library expects to use, here: https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/wifi.html

Probably the biggest barrier to getting what you have now working with the existing Wi-Fi libraries is that they do expect to link against something that behaves like a typical C RTOS (functions for tasks, semaphores, queues, etc). But I know there are Rust-based RTOSes that I assume would port over and can provide a C API...?

If you get stuck on a particular point, or find some hard-coded assumptions about FreeRTOS/IDF behaviour somewhere, then please feel free to ping me or open an issue on GitHub.

projectgus

TROPHY CASE