search

mccloudaero / evpr

Electric Variable Pitch Rotor
http://mccloudaero.com
GNU General Public License v3.0
2 stars 1 forks source link

Flashing Inconsistencies #74

Closed GeorgesOatesLarsen closed 3 years ago

GeorgesOatesLarsen commented 3 years ago

Prototypes have been displaying sporadic refusal to flash.

Behavior is inconsistent on the order of weeks or months, but consistent on a particular day. Some days the boards work fine. Some days, they do not ("Invalid head of packet" is the typical esptool error). Possibly caused by floating charge on ??? pin. Expected behavior and best practices are poorly documented, so it is difficult to pinpoint an exact cause.

The basic reset/reprogram transistor pair (the "esptool circuit") is correctly implemented. However, detailed testing on scope (on poor-performance days) shows extremely unstable behavior (strange oscillation, rather than expected flatline high/low reset signals) on RESET/BOOTMODE. However, this observation is extremely inconsistent. Attempts to recreate it after adding a capacitor and removing it have failed. This all suggests, again, that the cause might be a floating pin.

There are two oft-cited solutions to this problem:

  1. Hidden in the implementation notes for SD card reading published Espressif themselves is the suggestion to short to the RESET signal. https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/sd_pullup_requirements.html

    When the GPIO2 pin is pulled high in accordance with the SD pull-up requirements, you cannot enter Download mode because. GPIO2 is a bootstrapping pin which in this case must be pulled low. For boards that require shorting the GPIO0 and GPIO2 pins with a jumper, put the jumper in place, and the auto-reset circuit will pull GPIO2 low along with GPIO0 before entering Download mode. For boards with components attached to their GPIO2 pin (such as pull-down resistors and/or LEDs), check the schematic of your development board for anything connected to GPIO2.

  2. Some sources indicate that a capacitor to ground on the RESET signal is helpful. https://pcbartists.com/design/esp32-cp2102-programmer-schematic/ https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection

    Some third party ESP32 development boards use an automatic reset circuit for EN & GPIO pins, but don't add a capacitor on the EN pin. This results in unreliable automatic reset, especially on Windows. Adding a 1uF (or higher) value capacitor between EN pin and GND may make automatic reset more reliable.

Neither solution, as of current revision, is implemented on EVPR. The capacitor solution appears to be implemented by Adafruit. Confoundingly, adding this capacitor has zero effect on the outcome of flashing. However, the way in which I was forced to add the capacitor meant it was far away from the ESP32. Potentially, a closer landing pad is necessary for it to work.

See Adafruit feather schematic here: https://cdn-learn.adafruit.com/assets/assets/000/041/630/original/feather_schem.png?1494449413

Suggestion 1., shorting I02 to BOOTMODE signal DID immediately fix the problem and yielded very reliable flashing. However, even more confoundingly, Adafruit implementation leaves IO2 floating, suggesting that it is possible to implement ESP32WROOM without this short. Why does our board need it? Does Adafruit have a custom bootloader that eliminates this issue?

Some sources suggest pullup on EN/RESET, which we do have: https://www.esp32.com/viewtopic.php?t=11913

Same source suggests that early CP2102N chips may have a power-on reset issue? Check date code -- 1639 or later should suffice. Current date code is 2036, so this is not our problem. https://www.silabs.com/documents/public/pcns/PCN-1611215-CP2102N-Datasheet-and-Errata-Update.pdf

Same source also suggests a capacitor from EN/RESET to 5V, which is not something I have tried. This is not implemented by the adafruit feather module.

Source here suggests both capacitor from EN to ground and pullup on EN: https://www.reddit.com/r/esp32/comments/i90hx1/autoprogramming_circuit_not_working/

Some boot mode selection documentation by espressif: https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection

Could this have anything to do with IO12, mentioned here and here? We do have DS_CLK on IO12. But that is directly connected to the SN74AHCT. Is it possible this is some how driving IO12 high?

Overall, it seems wise to add a closed solder jumper from IO2 to IO0. Consider adding landing pads for capacitors between RESET and both GND/5V. Consider transplanting adafruit ESP32 module to test for bootloader differences.

GeorgesOatesLarsen commented 3 years ago

So that short from IO2 to IO0 actually prevents the reset button from working. We need a different solution.

GeorgesOatesLarsen commented 3 years ago

I am leaving this arguably duplicate issue open for now. I have a strong suspicion that we've been dealing with multiple issues. One, a design problem due to the lack of that capacitor. The other due to process issues leading to the unpredictably faulty flashing observed here. I think the process issues in the boards I reference above meant that even when I fixed the capacitor issue, I still saw problems flashing. However, DUT6 from #76 is extremely consistent. I am hoping to repeat some of the ideas here and actually get waveforms for them so that I can conclude finally on what could be causing our flashing issues. This issue will probably be closed no matter what the results are, but I want to get certainty first.

GeorgesOatesLarsen commented 3 years ago

This behavior has been resolved, see #76.