Unreliable GPIO
Re: Unreliable GPIO
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 !!
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 !!
Last edited by Aidin77 on Sat Jun 27, 2020 8:26 am, edited 1 time in total.
- jgustavoam
- Posts: 164
- Joined: Thu Feb 01, 2018 2:43 pm
- Location: Belo Horizonte , Brazil
- Contact:
Re: Unreliable GPIO
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.)
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.)
Retired IBM Brasil
Electronic hobbyist since 1976.
Electronic hobbyist since 1976.
Re: Unreliable GPIO
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 !
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 !
- Attachments
-
- does not work.png (16.66 KiB) Viewed 9730 times
-
- bug main area 1.png (68.3 KiB) Viewed 9730 times
-
- bug main area 2.png (93.25 KiB) Viewed 9730 times
Re: Unreliable GPIO
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
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
& I also believe that IDF CAN should be fixed.
Re: Unreliable GPIO
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.
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.
Code: Select all
GPIO.out_w1ts = BIT(21);
// some constant-time integer calculations
GPIO.out_w1tc = BIT(21);
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
- Posts: 164
- Joined: Thu Feb 01, 2018 2:43 pm
- Location: Belo Horizonte , Brazil
- Contact:
Re: Unreliable GPIO
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.
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.
Retired IBM Brasil
Electronic hobbyist since 1976.
Electronic hobbyist since 1976.
Re: Unreliable GPIO
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.
Not sure if I mentioned it anywhere, but core 1 code is fully in IRAM. So flash delays not possible either.
Re: Unreliable GPIO
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:jeeves wrote: ↑Fri Jun 26, 2020 5:06 pmhttps://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.
- 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
Re: Unreliable GPIO
Hmm, let me guess....Saleae16 clone arrived
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).
Your reference does not appear in thread. Would you please reference this quote/statement?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.
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'
& I also believe that IDF CAN should be fixed.
Re: Unreliable GPIO
@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
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
Who is online
Users browsing this forum: No registered users and 55 guests