Unreliable GPIO

[Aidin77]

Thank you for your guidance, I submitted the code in the Github too.

I`m not expert in esp32 and RTOS environment as you are, and section 3.3 esp32 errata, confused me.
" When the CPU accesses peripherals and writes a single address repeatedly, some writes may be lost. "
And this happened for me.
I don`t know this error related to esp32 hardware, driver or some where else like atomic issues !!

[jgustavoam]

Hi Aidin,
I suggest you read the manual with attention.
Wich revision is your ESP32?

https://www.espressif.com/sites/default ... p32_en.pdf

Findout Revision:
https://github.com/espressif/esp-idf/bl ... rld_main.c

Fixes:
This issue is fixed in silicon revision 1.

Details:
Some ESP32 peripherals are mapped to two internal memory buses (AHB & DPORT).
When written via DPORT, consecutive writes to the same address may be lost.
Workarounds:
This issue is automatically worked around in the drivers of ESP-IDF V1.0 and newer.
Workaround Details:
When writing the same register address (i.e., FIFO-like addresses) in sequential instructions,
use the equivalent AHB address not the DPORT address.
(For other kinds of register writes, using DPORT registers will give better write
performance.)

[Aidin77]

Thank you jgustavoam,

Yes i read it several times and also i had checked my chip version and it seems that it must works fine without any change in GPIO AHB address ( due to version one ), but it does not work fine.
So i decided to use a patch according to [url]https://github.com/NeoCat/ESP32-P3RGB64x32MatrixPanel/blob/master/README.md[/url]

please see the images ( main resource of error ) that i don`t know how i can solve it.

I changed GPIO but i`m not sure this is correct AHB address !!

May be this issue related to Arduino environment !

[PeterR]

Assuming that your issue is silicon then:
Upgrade to latest or rc/beta.

I would be very suprised (& in horror) if there are not both patches and a IDF/Ardunio version which supports this fix.
The silicon issue has been understood for a while and is not a casual 'oops' - the issue is very much in your face (& every library you use).
So I am thinking that you should just checkout latest?
Try a git checkout etc etc

[jeeves]

Saleae16 clone arrived, but sigrok is having issues on keeping it dumping more than a couple sec. Anyway, I found some random lag spikes of up to ~720 cycles (~3us), which shouldn't be possible - in the memw thread, ESP_Sprite says memw should take at most a hundred cycles, and the GPIO.out_w1* write is described nowhere as having such delays.

Code: Select all

GPIO.out_w1ts = BIT(21);
// some constant-time integer calculations
GPIO.out_w1tc = BIT(21);

This is on core 1, the isolated core, and with the APB bus modification. Using 1MHz sample rate (the low rate due to the sigrok issue above), 99.9% of the pulses are just one us, but then there are spikes to up to four us. Meaning either memw or the APB write are taking extra time of up to three microseconds - there are no IRQs set on the core, and an UNICORE config shouldn't be trying to stop the second core from core 0 anywhere.

Before someone suggests aliasing - that the zero portion is being missed - that's not possible, since the pulse downtime is ~four microseconds. 1MHz rate could only miss samples of 1us.

[jgustavoam]

Hi Jeeves
You can not use a 1MHz sample rate to detect this type of problem! If it really exists. Use 24 MHz sample rate.
Correct the problem of your Logic Analyzer. What is your analyzer?
May be I help you.

[jeeves]

https://sigrok.org/wiki/Mcupro_Logic16_clone

Not sure if I mentioned it anywhere, but core 1 code is fully in IRAM. So flash delays not possible either.

[p-rimes]

https://sigrok.org/wiki/Mcupro_Logic16_clone

Not sure if I mentioned it anywhere, but core 1 code is fully in IRAM. So flash delays not possible either.

I have one of these (or a similar clone + enclosure) and I also use sigrok. If you can't achieve 40MHz on 2 channels, your issues could be one of these gotchas:

• Poor quality USB cable or hub
• Old sigrok/PulseView version (I use nightly)
• Too many channels enabled. You can only get reliably above ~12MHz by reducing active channel counts

[PeterR]

Saleae16 clone arrived

Hmm, let me guess....
I don't normally run on Ethos but Saleae's products rock & a clone, realy? (It is way more expansive than 5 years ago granted).

I found some random lag spikes of up to ~720 cycles (~3us), which shouldn't be possible - in the memw thread, ESP_Sprite says memw should take at most a hundred cycles, and the GPIO.out_w1* write is described nowhere as having such delays.

Your reference does not appear in thread. Would you please reference this quote/statement?

Regardless; you have a random 3uS delay. The two options I can think of are; (a) someone is interrupting you, (2) something we don't understand. Both are quickly localised with a few binary chops. The 'binary chop' is more effective than any Jackie Chan/Bruce Lee Kung Foo move & is available to any novice. The secret is to let go of any preconceptions and just (even randomly) remove half the code - by which I mean remove device initialisation/other main initialised code. Many simply focus on removing the stuff which they think is the problem & so then fail.

PS
I am quite interested in how this runs. Have seen a few weird ESP things but only you can boil this down with a Zen like 'binary chop'

[jeeves]

@p-rimes
I use sigrok's latest stable (sigrok-cli 0.7.1, libsigrok 0.5.2/5:1:1), and I tried with three channels at most rates. I opened this bug https://sigrok.org/bugzilla/show_bug.cgi?id=1565 . Poor quality USB is a possibility, I use the USB B cable that came with the unit. However it's looking like a sigrok bug, as the dumping stops when cpu hits 100%.

@jgustavoam
You're right that higher sample rates would be needed to be sure, even with some manual code delays. Do you happen to have a devkitC or similar? If I posted the binary, could you measure pin 21 on the highest sample rate your analyzer has, and see how it varies, during 10s or so?

Our environments differ at least in wifi, mine is connected and yours will be in disconnected state. It'd be a data point at least. I have no trouble sharing the binary, sdkconfig or code snippets, just not the full source.

@PeterR
30$ vs 300$. Not willing to spend huge amounts of cash for something I'll only use once or twice. Plus the clones were recommended on another forum.

memw link: viewtopic.php?f=2&t=16180#p61589

Re binary bisect: while usually good, in this case it's more likely a missing disable instead of an extraneous enable (or a hw limitation or bug). Taking out startup code parts would just cause it to not start up, haha.

It does appear I'm the first person who got this type of dual-core setup successfully running. Earlier threads gave up, or pinned a FreeRTOS task and disabled the watchdog, etc. So it's a chance there's esp-idf code not guarded by UNICORE defines affecting the second core somewhere, after all they wouldn't notice it, as UNICORE testing is usually to save power or to avoid possible SMP bugs.

It could also be a number of other things of course. Rather hard to pin down