Unreliable GPIO
Unreliable GPIO
I'm seeing unreliable GPIO results on my esp32; apparently both reading and writing. About 1 in 30-100k reads/writes has the wrong result (a high bit read as 0, low bit read as 1, set bit or cleared bit not taking effect, etc).
The board is rev1. Esp-idf is the 4.0 git branch. I've configured idf as unicore, and I'm running custom code on the second core, dedicated to serving the GPIO in real time. This should allow no delays, as there are no IRQs and no FreeRTOS on that core. I poll instead of using IRQs to work around the GPIO IRQ errata, and to get higher speed. I've disabled hw AES/etc in the idf config, to minimize core 0's DPORT accesses.
The setup is otherwise working, but for the unreliable GPIO results. It appears not to be a timing issue, as I benched the handling iteration with xthal_get_ccount(), and the longest took 255 cycles, when the limit is ~335. I don't have an oscilloscope currently (ordered a cheap one from ali yesterday), but the timing is probably not the cause.
I doubt it's a soldering or component issue either, those would fail way more often.
Errata 3.3 should not affect this board since it's rev 1. 3.10, 3.16, 3.18 may, but I'm unsure. I've tried so far:
- edited PROVIDE ( GPIO = 0x3ff44000 ) in esp32.peripherals.ld to 0x60004000, and verified it took place by objdump disassembly
- added __sync_synchronize(); after every GPIO.out_w1tc/out_w1ts write. It causes a full compiler barrier and emits a memw, verified in disassembly (gcc correctly emits a memw before all such accesses, as well as before GPIO.in reads)
The erratas do not mention the high AHB/APB area at 0x60004000, only the lower one, not sure if it means the GPIO area is unaffected or if the errata is faulty.
Anyway, any ideas? Anyone seen similar?
The board is rev1. Esp-idf is the 4.0 git branch. I've configured idf as unicore, and I'm running custom code on the second core, dedicated to serving the GPIO in real time. This should allow no delays, as there are no IRQs and no FreeRTOS on that core. I poll instead of using IRQs to work around the GPIO IRQ errata, and to get higher speed. I've disabled hw AES/etc in the idf config, to minimize core 0's DPORT accesses.
The setup is otherwise working, but for the unreliable GPIO results. It appears not to be a timing issue, as I benched the handling iteration with xthal_get_ccount(), and the longest took 255 cycles, when the limit is ~335. I don't have an oscilloscope currently (ordered a cheap one from ali yesterday), but the timing is probably not the cause.
I doubt it's a soldering or component issue either, those would fail way more often.
Errata 3.3 should not affect this board since it's rev 1. 3.10, 3.16, 3.18 may, but I'm unsure. I've tried so far:
- edited PROVIDE ( GPIO = 0x3ff44000 ) in esp32.peripherals.ld to 0x60004000, and verified it took place by objdump disassembly
- added __sync_synchronize(); after every GPIO.out_w1tc/out_w1ts write. It causes a full compiler barrier and emits a memw, verified in disassembly (gcc correctly emits a memw before all such accesses, as well as before GPIO.in reads)
The erratas do not mention the high AHB/APB area at 0x60004000, only the lower one, not sure if it means the GPIO area is unaffected or if the errata is faulty.
Anyway, any ideas? Anyone seen similar?
Re: Unreliable GPIO
this is also my problem :
after a while you could see some runt event on signal !! ( oscilloscope: model Hantek 20Mhz )
void setup()
{
gpio_config_t io_conf;
io_conf.mode = GPIO_MODE_OUTPUT;
io_conf.pin_bit_mask = 0b10100;
gpio_config(&io_conf);
}
void loop()
{
GPIO.out_w1ts = 0b10100;
GPIO.out_w1tc = 0b10100;
}
after a while you could see some runt event on signal !! ( oscilloscope: model Hantek 20Mhz )
void setup()
{
gpio_config_t io_conf;
io_conf.mode = GPIO_MODE_OUTPUT;
io_conf.pin_bit_mask = 0b10100;
gpio_config(&io_conf);
}
void loop()
{
GPIO.out_w1ts = 0b10100;
GPIO.out_w1tc = 0b10100;
}
- Attachments
-
- RuntTrigger-4.png (6.62 KiB) Viewed 11017 times
-
- pulse.pdf
- direct port
- (12.66 KiB) Downloaded 583 times
- jgustavoam
- Posts: 164
- Joined: Thu Feb 01, 2018 2:43 pm
- Location: Belo Horizonte , Brazil
- Contact:
Re: Unreliable GPIO
Hi Aidin,
Your Scope is inadequate do capture the signal generated by the your program!!
The ESP32 clock ís too fast to your 20 MHz scope. Test with another fastest scope.
The irregular image is normal, because you are using under sampling frequency.
Your Scope is inadequate do capture the signal generated by the your program!!
The ESP32 clock ís too fast to your 20 MHz scope. Test with another fastest scope.
The irregular image is normal, because you are using under sampling frequency.
Retired IBM Brasil
Electronic hobbyist since 1976.
Electronic hobbyist since 1976.
Re: Unreliable GPIO
" Hi Aidin,
Your Scope is inadequate do capture the signal generated by the your
program!!
The ESP32 clock ís too fast to your 20 MHz scope. Test with another fastest scope.
The irregular image is normal, because you are using under sampling frequency.
Retired IBM Brasil
Electronic hobbyist since 1976. "
Hi
Thank you for your answer, so i should change my scope what about logic analyzer ?
but why there are some noises on output pins according the above program ?
please visit this:
https://github.com/NeoCat/ESP32-P3RGB64x32MatrixPanel.
"
Patching GPIO to avoid eratta of ESP32
You should patch the tools/sdk/ld/esp32.peripherals.ld to avoid random pixel noise on the display as following:
/* PROVIDE ( GPIO = 0x3ff44000 ); */
PROVIDE ( GPIO = 0x60004000 );
Please refer section 3.3. in https://www.espressif.com/sites/default ... p32_en.pdf for more details. "
my chip version is one and this patch does not work !!
Your Scope is inadequate do capture the signal generated by the your
program!!
The ESP32 clock ís too fast to your 20 MHz scope. Test with another fastest scope.
The irregular image is normal, because you are using under sampling frequency.
Retired IBM Brasil
Electronic hobbyist since 1976. "
Hi
Thank you for your answer, so i should change my scope what about logic analyzer ?
but why there are some noises on output pins according the above program ?
please visit this:
https://github.com/NeoCat/ESP32-P3RGB64x32MatrixPanel.
"
Patching GPIO to avoid eratta of ESP32
You should patch the tools/sdk/ld/esp32.peripherals.ld to avoid random pixel noise on the display as following:
/* PROVIDE ( GPIO = 0x3ff44000 ); */
PROVIDE ( GPIO = 0x60004000 );
Please refer section 3.3. in https://www.espressif.com/sites/default ... p32_en.pdf for more details. "
my chip version is one and this patch does not work !!
Re: Unreliable GPIO
Logic analyser would be the cheaper option & fine as you are sampling digital signals not voltages. Saleae rock, at a price.
I think perhaps you can work with what you have FTM.
In you're original post you say
What frequecy are you trying to generate and/or sample. What do you use to generate the input and how do you draw the conclusion that the ESP has it wrong?
It is quite possible that this is about aliasing but all the same would seem wise to break it down.
I think perhaps you can work with what you have FTM.
In you're original post you say
What make you think that the signal is wrong?About 1 in 30-100k reads/writes has the wrong result (a high bit read as 0, low bit read as 1, set bit or cleared bit not taking effect, etc).
What frequecy are you trying to generate and/or sample. What do you use to generate the input and how do you draw the conclusion that the ESP has it wrong?
It is quite possible that this is about aliasing but all the same would seem wise to break it down.
& I also believe that IDF CAN should be fixed.
Re: Unreliable GPIO
Yes, the model I ordered was a Saleae16 clone. I'm a sw guy, little electronics experience - I thought that's just a digital oscilloscope, displaying things via usb instead of its own screen. What do you mean with FTM? Google results aren't helpful for that.
There is no set frequency, this is a situation where both ends are bit-banging. I control both ends. The ESP is a slave, it must respond to each bit the master sends or requests. There is one wire for clock, one wire for input, one for output. The clock line does not send a periodical clock, it sends a pulse when the master has sent a bit or expects to receive one.
As mentioned above, the ccount timing result shows plenty of headroom. The software for both ends has been verified in emulation, on a computer setup - the logic is correct. I have also verified the data being sent by ESP is correct in its RAM, and the data being sent by the device is correct in its RAM, the error is in the GPIO lines somewhere.
I send or receive known data, and the other end finds it differs by one bit somewhere.What make you think that the signal is wrong?
There is no set frequency, this is a situation where both ends are bit-banging. I control both ends. The ESP is a slave, it must respond to each bit the master sends or requests. There is one wire for clock, one wire for input, one for output. The clock line does not send a periodical clock, it sends a pulse when the master has sent a bit or expects to receive one.
As mentioned above, the ccount timing result shows plenty of headroom. The software for both ends has been verified in emulation, on a computer setup - the logic is correct. I have also verified the data being sent by ESP is correct in its RAM, and the data being sent by the device is correct in its RAM, the error is in the GPIO lines somewhere.
Re: Unreliable GPIO
That topic doesn't seem relevant? It's about really fast signal generation, 10 MHz, while mine is about messaging at <2 MHz, currently in the ~700 kHz range.
- jgustavoam
- Posts: 164
- Joined: Thu Feb 01, 2018 2:43 pm
- Location: Belo Horizonte , Brazil
- Contact:
Re: Unreliable GPIO
Hi Aidin,
See the captured image from my Scope Tektronix TB1062 (60 MHz / 1 Giga Samples/s).
The correct image on the pins GPIO2 and GPIO4 is below. No problem..
Arduino code:
See the captured image from my Scope Tektronix TB1062 (60 MHz / 1 Giga Samples/s).
The correct image on the pins GPIO2 and GPIO4 is below. No problem..
Arduino code:
Code: Select all
void setup()
{
gpio_config_t io_conf;
io_conf.mode = GPIO_MODE_OUTPUT;
io_conf.pin_bit_mask = 0b10100;
gpio_config(&io_conf);
}
void loop()
{
GPIO.out_w1ts = 0b10100;
GPIO.out_w1tc = 0b10100;
}
Retired IBM Brasil
Electronic hobbyist since 1976.
Electronic hobbyist since 1976.
Re: Unreliable GPIO
Thank you,
But it is not stable, and esp32 lose some data on its output ( it could be checked via software ,LCD or LED matrix ) and if you check the outputs, it is not stable in some cases it ( like a random noise even on Version 1 ).
I searched it seriously, this is a problem for many people, and I hope it will be solved by helping the expertise:
https://github.com/espressif/esp-idf/issues/3862
https://qiita.com/h_nari/items/d52734440a7256072e8e
I decided to use it as a parallel port instead of I2S ( without DMA) because it is not very good for many cases. In addition, as you know in other microcontrollers do it easily and I think the modern soc like esp32 should do it!!
Regards
But it is not stable, and esp32 lose some data on its output ( it could be checked via software ,LCD or LED matrix ) and if you check the outputs, it is not stable in some cases it ( like a random noise even on Version 1 ).
I searched it seriously, this is a problem for many people, and I hope it will be solved by helping the expertise:
https://github.com/espressif/esp-idf/issues/3862
https://qiita.com/h_nari/items/d52734440a7256072e8e
I decided to use it as a parallel port instead of I2S ( without DMA) because it is not very good for many cases. In addition, as you know in other microcontrollers do it easily and I think the modern soc like esp32 should do it!!
Regards
Code: Select all
#define GPIO5 5 // bit 0
#define GPIO22 22 // bit 1
#define GPIO1 25 // bit 2
#define GPIO3 26 // bit 3
#define GPIO21 21 // bit 4
#define GPIO19 19 // bit 5
#define GPIO18 18 // bit 6
#define GPIO23 23 // bit 7
#define GPIO17 17 // for latch
// clear_parameter for clearing bit0~7 output
uint32_t clear_parameter=(1 << 23 ) | (1 << 22) | (1 << 25) | (1 << 26) | (1 << 21) | (1 << 19) | (1 << 18) | (1 << 5)| (1 << 17);
unsigned int test,temp[1919];
char x[1919],k,j=0;
static unsigned int a0=0b00000000000000000000000000000001;
static unsigned int a1=0b00000000000000000000000000000010;
static unsigned int a2=0b00000000000000000000000000000100;
static unsigned int a3=0b00000000000000000000000000001000;
static unsigned int a4=0b00000000000000000000000000010000;
static unsigned int a5=0b00000000000000000000000000100000;
static unsigned int a6=0b00000000000000000000000001000000;
static unsigned int a7=0b00000000000000000000000010000000;
void setup()
{
gpio_config_t io_conf;
io_conf.mode = GPIO_MODE_OUTPUT;
io_conf.pin_bit_mask |= (1 << 23 ) | (1 << 22) | (1 << 25) | (1 << 26) | (1 << 21) | (1 << 19) | (1 << 18) | (1 << 5)| (1 << 17);
gpio_config(&io_conf);
// fill buffer
for ( int i=0; i<=1919 ;i++){
x[i]=0xff>>j;
j++;
if ( j==9 ) {
j=0;
};
};
//-------------------------------------------------------------------------------------------------------------------
for (int i=0; i<=1919; i++){
temp[i]=((x[i]&a0)<<GPIO5)|((x[i]&a1)<<21)|((x[i]&a2)<<23)|((x[i]&a3)<<23)|((x[i]&a4)<<17)|((x[i]&a5)<<14)|((x[i]&a6)<<12)|((x[i]&a7)<<16)| (1 << 17);
}
}
void loop()
{
for ( int i=0; i<=1919 ;i++){
GPIO.out_w1tc=clear_parameter;
GPIO.out_w1ts=temp[i];
};
}
Re: Unreliable GPIO
If you are convinced it is bug, then github is better place to create issue, instead of this in 5 other, not related, topics:
You will have chance to show espressif developers results. So far you dont accept answers from other users, so maybe its not a real issue in esp-idf.Hi
Please visit this post ( Unreliable GPIO ):
viewtopic.php?p=61753#p61753
Any idea !!
Who is online
Users browsing this forum: No registered users and 75 guests