search

riscv-rust / riscv-rust-quickstart

A template for building Rust applications for HiFive1 boards
205 stars 24 forks source link

Hifive1 RevB spi_wifi.rs example does not work #12

Closed o080o closed 4 years ago

o080o commented 4 years ago

After compiling, and flashing the spi_wifi.rs example to a hifive1 revb board, the example does not work.

Expected to see this over the terminal:

WiFi Test resp: OK\r\n

Instead, I get this over the terminal:

WiFi Test resp: Err(ProtocolError)

Looking at the actual response packet, this is the actual response from the esp chip (4 byte array):

[67, 0, 0, 0]

Which doesn't match the expectation in the code that the 4th byte == 0x42.

In addition, there seems to be absolutely no documentation about this spi protocol anywhere from SiFive or Espressif. The only links I can find simply lead back to this example code xD seems the only way this was figured out was reverse engineering from the bootloader... which is something I'd rather not have to do...

Also, in case it is relevant somehow, for flashing, I've been using this script, modified from the sifive freedom sdk makefiles,:

cargo build if [ $? -ne 0 ] then exit 1 fi HEX_FILE=flashed.hex $RISCV_PATH/bin/riscv64-unknown-elf-objcopy -O ihex $1 $HEX_FILE echo -e "loadfile $HEX_FILE\n\rnh\nexit" | JLinkExe -device FE310 -if JTAG -speed 4000 -jtagconf -1,-1 -autoconnect 1

Hopefully I'm just being dumb about something here :D

Disasm commented 4 years ago

Could you check both debug and release builds?

o080o commented 4 years ago

it works in release builds! yay!

Do you know what the difference would be here? some sort of timing issue maybe?

Disasm commented 4 years ago

This ESP32 module is quite timing-sensitive. Anyway, at 320MHz this should not be a problem. I need to investigate this.

Disasm commented 4 years ago

Well, it turns out you have to pull CS high quickly after the packet data is sent. In the bootloader it is pulled one clock period after the last bit and in this example (in release mode) it's pulled right after the last bit. However, in debug it's pulled after a random amount of time. One attempt out of ten it's pulled in a right time (I mean, only 6 cycles after the last bit), resulting in a good transfer.

ajbt200128 commented 3 years ago

Ran into this issue a few times trying to use the example, and finally realized 320MHz fixes it too. Do we want to change the example to set the clock speed to this? I can create a PR if that sounds good

Disasm commented 3 years ago

While we don't have a better solution at the moment, this sounds like a good fix. Please go ahead and make a PR.