Newer IDF Support

[andrewleech]

Hello, Has any work been done to support newer IDF versions? I'd like to port this project to ESP32C6 to use this tiny module: https://docs.m5stack.com/en/core/M5NanoC6 However, it requires IDF 5.2 or newer, which has compatibility changes in things like the SPI drivers etc.

[windowsair]

Not yet. But I don't think it should make much difference. Perhaps the focus is on wifi connection and uart related API? Anyway, give it a try and feel free to discussing the details here :)

[andrewleech]

I did give it a quick try and there was quite a long list of compile errors, many from the SPI drivers I think.

[windowsair]

SPI operates by directly reading and writing registers. I'm not sure if the spi ip has changed.

[andrewleech]

Ah, I was trying to build for C6 so yeah, it's probably different registers there. I basically just naively copied the C3 implementation as a first try, but I know C6 requires newer IDF and newer APIs in it, it would make sense that different IP / register layout would be behind that.

[windowsair]

Interestingly, the register layout of C3 and S3 seems to be the same. Not sure if the new version of sdk changes the layout like C3. I think it could first check if C3 and C6 have similar registers in v5.2 sdk.

[andrewleech]

I was going to try building with S3 instead to see how much effort it would take, but thought I'd better get the current master tested first on the S3 to be sure any changes made worked properly.

Unfortunately I can't make the S3 work correctly however. Unmodified code (other than wifi configuration) runs on my S3 module, I can connect with usbip and pyocd/openocd but it can't communicate with any arm chips I try to debug (stm32wb55, rp2040, stm32f405). It just gives a no ack.

Oscilloscope shows signals on swdio and swclk so the pinout appears correct, just not actually working.

This is all a separate issue to the IDF version certainly, it's just blocking me from doing much else currently.

[windowsair]

Try to use lower speed? May be < 1Mhz?

[andrewleech]

Try to use lower speed? May be < 1Mhz?

xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-17:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDLiveWatchSetup
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
adapter speed: 100 kHz

Info : Using CMSIS-DAPv2 interface with VID:PID=0xc251:0xf00a, serial=1234
Info : CMSIS-DAP: SWD  supported
Info : CMSIS-DAP: JTAG supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.1.0
Info : CMSIS-DAP: Serial# = 1234
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 100 kHz
Error: Error connecting DP: cannot read IDR

[windowsair]

Is the oscilloscope showing the expected waveform? It is also possible that the GPIO is not reading the correct input, have you connected the 3.3V pin?

[andrewleech]

I'm not too certain about what the expected waveform is, but both SWD lines have some switching / communication when trying to start a debug session. The S3 is powered from the target processor 3v3 (and gnd) lines. I've only got gnd, SWDIO and SWDCLK wired on the debug port, they're connected to the documented gpio pins for the S3 so I don't think there should be be any mismatch there or problem reading the pins. The same target debug connector works with a stlink.

I think I've got a basic esp32 somewhere, if I can find that I'll try it instead, see if I can get basic operation going at least

[windowsair]

You can just post the waveform you captured here. I think you can see at least 50 cycles of SWCLK at the beginning

[andrewleech]

This is the clock and data lines at the start of running openocd

[andrewleech]

Update: ok it sometimes works. I re-tested on a different target board that has the debug connected wired directly to MCU pins on short wires and the S3 build now works for me. It's a STM32F411 and it works at 800Khz and 8000Khz but not 10000Khz

The target that doesn't work I've pulled the schematic for and it's got some pull resisters on the debug port. I would have thought they're all weak enough to not cause an issue, but the S3 debugger still does not work here:

I also tried again on a rp2040 with debug header wired directly to the MCU pins - still doesn't work here, cannot connect with the same: Error: Error connecting DP: cannot read IDR A Jlink connected to the same debugging port works fine.

So perhaps there's a drive strength issue, have you ever experimented with the settings for this? I tried a quick

__STATIC_INLINE void DAP_SETUP(void)
{
  // Connecting non-SWD pins to GPIO
  GPIO_FUNCTION_SET(PIN_TDO);
  GPIO_FUNCTION_SET(PIN_TDI);
  GPIO_FUNCTION_SET(PIN_nTRST);
  GPIO_FUNCTION_SET(PIN_nRESET);

  gpio_ll_set_drive_capability(&GPIO, PIN_SWDIO_MOSI, 3);
  gpio_ll_set_drive_capability(&GPIO, PIN_SWCLK, 3);

But that seemed to completely break it, doesn't work on any target now.

[andrewleech]

Ah, sorry I've looked through many other issues here and it looks like I've just run into some similar issues to others, like https://github.com/windowsair/wireless-esp8266-dap/issues/68#issuecomment-1988363428 and https://github.com/windowsair/wireless-esp8266-dap/issues/31#issuecomment-1668264540

With pyocd locking the freq to 10mhz did make it work on a samd21 target I was testing with ! On other frequencies it couldn't even reset the board.

I gather there's some surprising timing issues with the likes of pyocd / openocd that trips it up on some targets. I found a original ESP32 and programmed it up, got the same results as the S3.

I don't have keil to test with, I use vscode / linux for my embedded work. If there's anything I can do to help with timing investigations I'd be happy to help!

[windowsair]

Glad to heart that.

When you select 10MHz speeds, you're actually using 40MHz SPI output. All other lower speeds are output directly from the GPIO. Openocd doesn't seem to like using high rates in the beginning, stable connection must be established before increase the clock. Not sure what's going on here.

[andrepan]

Hello guys, I did some test on ESP-S2, but in my test, I found we can't use the SPI to only receive 3-bit . if i did this in the code , although i could found the 3 pluses, but i could not get data in the spi data registers. in the S2 and S3's TRM , I found this note "The length of transferred data must be in unit of bytes, otherwise the extra bits will be lost. The extra bits here means the result of total data bits % 8."