Unreliable GPIO

jeeves
Posts: 17
Joined: Wed Jun 17, 2020 2:35 pm

Unreliable GPIO

Postby jeeves » Wed Jun 17, 2020 2:55 pm

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?

Aidin77
Posts: 7
Joined: Thu Apr 19, 2018 6:56 pm

Re: Unreliable GPIO

Postby Aidin77 » Thu Jun 18, 2020 7:46 pm

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;

}
Attachments
RuntTrigger-4.png
RuntTrigger-4.png (6.62 KiB) Viewed 1218 times
pulse.pdf
direct port
(12.66 KiB) Downloaded 49 times

User avatar
jgustavoam
Posts: 74
Joined: Thu Feb 01, 2018 2:43 pm
Location: Belo Horizonte , Brazil
Contact:

Re: Unreliable GPIO

Postby jgustavoam » Fri Jun 19, 2020 1:59 am

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.

Aidin77
Posts: 7
Joined: Thu Apr 19, 2018 6:56 pm

Re: Unreliable GPIO

Postby Aidin77 » Fri Jun 19, 2020 2:47 pm

" 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 !!

PeterR
Posts: 441
Joined: Mon Jun 04, 2018 2:47 pm

Re: Unreliable GPIO

Postby PeterR » Fri Jun 19, 2020 11:39 pm

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
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 make you think that the signal is wrong?
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.

jeeves
Posts: 17
Joined: Wed Jun 17, 2020 2:35 pm

Re: Unreliable GPIO

Postby jeeves » Sat Jun 20, 2020 6:06 am

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.

What make you think that the signal is wrong?
I send or receive known data, and the other end finds it differs by one bit somewhere.

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.

jeeves
Posts: 17
Joined: Wed Jun 17, 2020 2:35 pm

Re: Unreliable GPIO

Postby jeeves » Sat Jun 20, 2020 3:51 pm

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.

User avatar
jgustavoam
Posts: 74
Joined: Thu Feb 01, 2018 2:43 pm
Location: Belo Horizonte , Brazil
Contact:

Re: Unreliable GPIO

Postby jgustavoam » Mon Jun 22, 2020 1:09 am

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:

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;
}
F0000TEK.JPG
Scope Image
F0000TEK.JPG (98.22 KiB) Viewed 898 times
Retired IBM Brasil
Electronic hobbyist since 1976.

Aidin77
Posts: 7
Joined: Thu Apr 19, 2018 6:56 pm

Re: Unreliable GPIO

Postby Aidin77 » Mon Jun 22, 2020 10:08 am

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

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];
       
        };
       
}

chegewara
Posts: 1180
Joined: Wed Jun 14, 2017 9:00 pm

Re: Unreliable GPIO

Postby chegewara » Tue Jun 23, 2020 5:35 pm

If you are convinced it is bug, then github is better place to create issue, instead of this in 5 other, not related, topics:
Hi
Please visit this post ( Unreliable GPIO ):

viewtopic.php?p=61753#p61753

Any idea !!
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.

Who is online

Users browsing this forum: Bing [Bot], jimhelios, u063096 and 14 guests