Wifi access

Is there any development on a better BSP for this board to support the initialisation of the esp32 solo ?
The only development I found is

  • the promose of a better driver somewhere in 2019
  • some reverse engineerings that don’t even use the metal library.
  • there is zephyr, but there as soon as you enable communication support the board does not have enough RAM. Strange, I thought the board did have enough memory.

Very strange to add a wifi chip and not being able to use it and no examples provided showing howto’s.
If this were there this is a very promising board for me.
I want to use C or C++

Yeah, it’s very strange and sad. New features not properly supported, and features such as using the Arduino IDE and libraries that worked great on the original HiFIve1 not supported.

I bought two rev Bs because the hardware looked great and I had ideas for using the WIFI but in the end I’m still using my original HiFive1 bought in December 2016 for everything.

I found this one GitHub - kjarvel/hifive1revb_wifi: SiFive HiFive1 Rev B ESP32 - WiFi connection demo
I tried doing it myself before using this, but it is almost impossible to communicate with the board. And even more strange, id works only if you move the elf file directly to the board and not if you start the debug in FreedomStudio.

Yes that is the reverse engineering I was referring to. The code was created by using a logic analyser and watching what happens at startup of the board, because then there is also some message exchange with the esp32-solo. I read all the documents about esp32 and I cannot map the code to the documentation. Again strange.
Some information I found on esp32 is in chinese. needless to say that this is not helpfull for me.

I tried also by using the same pattern of messages explained in the example, both with metal library and direct register programming, but it just didn’t work
I expect some doc will be released in a near future, it’s absurd you’ve got a feature and you can’t even use it


I’ve managed to successfully send data over wifi with Rust. I’m basing my work on the RISC-V Rust quickstart repo, specifically the spi_wifi.rs example. I built a small REPL using some code I wrote to read user input and the code in that example to read the responses from the ESP32. I also referenced the ESP32 AT Instruction Set manual pretty heavily, especially the documentation for the AT+CWMODE, AT+CWJAP, AT+CIPSTART, and AT+CIPSEND commands. Something that I didn’t realize when starting working with the chip is that it’s chattier than I expected: I needed to make multiple calls to the recv() function in the spi_wifi.rs example to empty the response buffer from the ESP32. Further, chapter 9 of the ESP32 manual is especially helpful: it contains sample conversations for several basic tasks.

I’m including my successful conversation log below, and should eventually have something more polished up on github for folks to play with. I want to point out that what I have is very hacky and ugly, but it works. I call recv() three times, as that seems to be enough to cover all the different cases. The right way to approach this would be a state machine, and I’ll look at building one for this when I put code up on github.


wifi> AT
wifi> AT+CWMODE=1
Ok("WIFI GOT IP\r\n")
wifi> AT+CIFSR
Ok("AT+CIPSTART=\"TCP\",\"REMOTE IP\",1234\r\n")
wifi> AT+CIPSEND=7
wifi> hello
Ok("\r\nRecv 7 bytes\r\n")
Ok("\r\nSEND OK\r\n")
wifi> AT

I sent AT+CIPSEND=7 because the code I have for my REPL appends \r\n to everything sent to the ESP, and the board reads everything you send after as what to send up to that number of bytes, so I had to account for the two extra bytes after the obligatory hello string (I did mention the code is ugly and hacky). The Err(WouldBlock)s here indicate superfluous recv() calls, as I described above. To receive data, I used nc -kl 1234 on my Mac. Usually, nc quits after the first connection, but -k keeps the program listening after clients disconnect. Helpful when debugging a client!


At startup of the board there are some AT commands sent to the ESP32 SOLO.
I used my raspberry pi to sample pins 11,12,13,15 and 16
I consider when CS becomes low, the start of a sequence
When the handshake becomes high, there is data available to be read.
SPI is bidirectional, but you cannot answer a question before hearing the question. So in the end, it is request reply mechanism.
I made use of pulseview to view the signals and try to make sense of them.
This is what I got:(MOSI followed by MISO most of the time :slight_smile: )

  1. 02 00 00 00 → we are going to send a command
    86 00 00 00 → I guess this is meaningless
  2. 06 00 00 41 → length = 6 41=‘A’
    C4 00 00 00
  3. 41 54 45 30 0D 0A → command = ATE0\r\n
    F8 F5 57 F7 6E 9A → meaningless
  4. 04 00 00 → makes no sense to me
    98 00 00
  5. 00 00 00 00
    0C 00 00 84 → maybe the length shifting 1 bit to the right = 06 00 00 42 where 42=‘B’
  6. 00 00 00 00 00
    82 A8 8A 60 68 → shift one bit to the right gives 41 54 45 30 34 → ATE04 (this is an echo off command being echoed I think because echo is still on, but the 4 is strange, the shifting as well)
  7. 01 00 00 00 → we are going to receive
    86 00 00 00
  8. 00 00 00
    0C 00 00 → I expected the length here and C=12 but the length = 6
  9. 00 00 00 00 00 00
    1A 14 9E 96 1A 14 → now this is strange, there should be 1 bit more , if I shift everything to the right
    I get 0D 0A 4F 4B 0D 0A \r\nOK\r\n (where is this bit going)
  10. 02 00 00 00
    86 00 00 00
  11. 0E 00 00 41 length = 14
    C4 00 00 00
  12. command = AT+BLEINIT=0\r\n
  13. 01 00 00 00
    86 00 00 00
  14. 00 00 00 00
    0C 00 00 84 → again the bit issue, shift right one bit = 06 00 00 42 (42=‘B’)
    in sequence 8 I would have expected this same bit sequence
  15. 00 00 00 00 00 00
    1A 14 9E 96 1A 14 : bit shift right : \r\nOK\r\n
    16)02 00 00 00
    86 00 00 00
  16. 0D 00 00 41 : length = 13
    C4 00 00 00
  17. AT+CWMODE=0\r\n
  18. 01 00 00 00
    86 00 00 00
  19. 00 00 00 00
    0C 00 00 84 → length = 6 after shift right 1 bit
  20. 00 00 00 00 00 00
    1A 14 9E 96 1A 14 → \r\nOK\r\n
    With this information I can try to create a program using the metal library and its SPI implementation
    Looking at the examples shared already there should not be this strange bit problem but I’ll see.
    My first goal is to be able to send AT commands and after a command is sent, to wait for the handshake and then to receive the response.
    I have seen the handshake getting high even during sending a command which puzzles me as well.
    In the long run, I hope to be able to use UDP and TCP with some socket like interface
    I don’t have a lot of spare time to do all this, but I’ll keep my research in sync here. Anyone can pick up ideas.
    I really want to use C or C++. That is what I know best.

The so called bit errors I am observing are likely caused because my PI is not the best logic analyser. A bit is easily missed.