What did you change in make menuconfig? That should be your first clue.

John A

I thought the 2nd stage bootloader was built anytime you make a change with menuconfig or the build directory is erased. I'm building with the same SDK all the time and I believe the 2nd stage bootloader is burned every time I do a make flash. Not even sure how you could build with a different ver o...

When the device boots it prints the 2nd stage bootloader sdk ver. But the version it prints is different than the "git describe" version from the IDF_PATH directory. So how does the bootloader have an ESP-IDF 3.1 version when the SDK is v3.0?

John A

I'm thinking this problem doesn't exist with the esp-idf. I am reading i2c from multiple tasks continuously.

John A

Might be worth checking the return code from recvfrom to see if it's returning with any errors in errno.

John A

licht77 wrote:@fly135: Yes - normally it works fine!
But there are several known flaws (eg i2c Write Issue #834) in the i2c implementation within esp32...

Don't know where you find #834. I checked the issues on the espressif/esp-if github and didn't see it.

John A

Just for reference I'm calling i2c functions in my app all the time and haven't experienced any issues.

John A

I've been trying to get help from others to verify an issue I'm seeing. Do you see a time to connect difference between WPA and WPA2 (PSK)? I am seeing multiple (random from 0 to 15 observed) disconnects with 203 reason code when using WPA2 (vs WPA). Which of course just lengthens the time it takes ...

Your code is burned into flash. When the code runs it is pulled from the flash and run from internal ram cache.

John A

Could be..I will try also bluetooth - wonder if it is also tcp-like protocol I think you should stick with TCP and figure it out. There is no reason that what you are trying to do shouldn't work other than obvious mistakes. Switching to Bt isn't really the issue. My less than subtle point was that ...