Pairing Pmod ESP32 and NUCLEO-L552ZE-Q

[Rahmadi]

Hi Everyone, I am wondering if the Pmod ESP32 can work with other boards such as NUCLEO-L552ZE-Q from ST Microelectronics? I tested the UART for Pmod ESP32 and it works well with the Xilinx/Digilent FPGA. However, when testing it with NUCLEO board, the UART communication is always stuck at receiving. Basically I send "AT" to Pmod ESP32 with the hope of getting back an "OK". This works with the FPGA but it's always stuck at waiting for OK with the NUCLEO board. I was wondering if Pmod ESP32 was made only for Digilent products.

Any help is appreciated. Thank you very much.

[JColvin]

Hi @Rahmadi,

In principle, the Pmod ESP32 is compatible with any other hardware, provided it is electrically and physically compatible (the Pmod ESP32 is designed with a 3.3 V supply in mind), so in that regard it was not made only for Digilent products. The IP core that we made was developed with the Pmod interface in mind, though if you are using a Xilinx FPGA, you could ostensibly set the constraints to what you need.

As for what is going on with the ESP32 and the ST microcontroller, it's hard to say for certain what is happening, though it's almost certainly an issue with the implementation (if it was an issue with the ESP32 itself, it wouldn't respond to the Xilinx FPGA either). It could be that the ESP32 needs some additional configuration before it is ready to receive inputs, the tx or rx pin on the microcontroller not being set to the correct output/input state, data is being received but not being correctly processed, the pin 9 on the ESP32 being driven high so it's expecting to receive SPI communication rather than UART data, etc. I don't know what setup you are using with the Nucleo board nor am I familiar with the ESP32 implementation that is available for it, so I'm not certain how much help I will be in terms of debugging it.

Thanks,
JColvin

[Rahmadi]

Hi @JColvin, thank you so much for clarifying the situation. My understanding was also that the Pmod ESP32 should work with any other hardware. We did not flash/re-flash it so it comes with its original firmware.

Could you please elaborate more on the requirements you said:

• the tx or rx pin on the microcontroller not being set to the correct output/input state,
• data is being received but not being correctly processed,
• the pin 9 on the ESP32 being driven high so it's expecting to receive SPI communication rather than UART data, etc

So, at least from this list, something specific that we did not set to be driven low is pin 9. Although, we did try connecting just the 4 pins (RX, TX, 3.3V, GND) to the FPGA, which means that pin 9 wasn't even used, and it still worked flawlessly (we sent AT and Pmod replied with OK). Could you please elaborate more on the TX and RX requirements (point 1), and about the data (point 2), and perhaps any other requirements (other than the obvious like baud rate 115200, etc.). We basically followed the Quick Start setup here: https://digilent.com/reference/pmod/pmodesp32/reference-manual both with the FPGA and the NUCLEO board.

Thank you so much for your help.

Thanks,

Rahmadi

[JColvin]

Hi @Rahmadi,

Since you are directly following the quick start guide from the Reference Manual, I'm anticipating you will have checked most of these already, but I'll list them on the chance that they were missed:

• The Tx and Rx checking was a check to make sure that whatever microcontroller pin that is connected to pin 2 on the Pmod ESP32 (RxD/MOSI) is set up to be transmitting data out of the microcontroller, and similarly the pin connected to pin 3 on the Pmod ESP32 (TxD/MISO) is set up to receive data from the attached peripheral.
  Sometimes the Rx/Tx conventions used by different pieces of hardware for which one is sending or receiving data are different from each other, so this recommendation was mostly a gut check to make sure the transmitting and receiving pin connections are not swapped.
• "Data is being received but not correctly processed". This is more unlikely of a situation, but this was to confirm that any data that is received by the Nucleo board from the Pmod ESP32 is successfully being read and displayed, as opposed to the Pmod ESP32 is sending the data, but the Nucleo board is not capturing the data in an array and sent to the host computer controlling the Nucleo board (via serial.receive or whatever the function might be for the microcontroller). Or that the data is being captured, but then the trigger to then display that data to the host computer controlling the Nucleo board is not working properly.
• "Pin 9 not being driven low". Based on your statement that when you connected just the 4 pins to the FPGA and still got a response from the module, this makes me think that the SW1 on the board (labeled SPI) is switched to the "off" position on the left so that the pulldown resistor is used to have the double-throw switch use the UART outputs rather than SPI. If you connected only those same four pins to the Nucleo board, I would then expect the same behavior; though note that if the pin 9 is actively being driven by the host board (whether FPGA or microcontroller), it will override whatever switch setting is connected.

I'm also guessing you are including the both the CR and the LF after sending the "AT" from the Nucleo board, otherwise the ESP32 module will not respond.

Thanks,
JColvin