Closed Evlers closed 10 months ago
I also found an indeterminate delay in the process_rx_task function.
event = (struct esp_priv_event *) (payload);
if (event->event_type == ESP_PRIV_EVENT_INIT) {
/* halt spi transactions for some time,
* this is one time delay, to give breathing
* time to slave before spi trans start */
stop_spi_transactions_for_msec(50000);
if (spi_drv_evt_handler_fp) {
spi_drv_evt_handler_fp(TRANSPORT_ACTIVE);
}
} else {
/* User can re-use this type of transaction */
}
stop_spi_transactions_for_msec ?
I added a 2s delay here that doesn't solve the problem either
In fact, the esp32 can receive the spi data from the host, but the host cannot receive the reply from the esp32
Actually, As you already observed, the master branch is much old for mcu. We have removed these things and mny more issues, added many optimization and customizations in feature/esp_as_mcu_host.
If you can actually try to get spi files similarly ported, you will automatically bump your experience. Make sure you do it on some dev branch, so that you do not loose everything yet made working.
Otherwise, you are just falling one by one issues that are already solved..
Okay, I'll try to porting feature/esp_as_mcu_host branch. Or there will be more problems waiting for me!!
I think manual compare for latest branch should be good to start with. I know I am asking a lot here and totally understand that you need to do this manually and might be a little confusing, without notion of the code.
But we do not have any faster solution for this for now. Once our other unrgent issues are over, we are going to introduce these all to easy portable any mcu. just that it might take some time.
We can help any issues you enter into.. even while merging this..
I think manual compare for latest branch should be good to start with. I know I am asking a lot here and totally understand that you need to do this manually and might be a little confusing, without notion of the code.
But we do not have any faster solution for this for now. Once our other urgent issues are over, we are going to introduce these all to easy portable any MCU. Just that it might take some time.
We can help any issues you enter into.. Even while merging this..
I think manual compare for latest branch should be good to start with. I know I am asking a lot here and totally understand that you need to do this manually and might be a little confusing, without notion of the code.
But we do not have any faster solution for this for now. Once our other unrgent issues are over, we are going to introduce these all to easy portable any mcu. just that it might take some time.
We can help any issues you enter into.. even while merging this..
I think manual compare for latest branch should be good to start with. I know I am asking a lot here and totally understand that you need to do this manually and might be a little confusing, without notion of the code.
But we do not have any faster solution for this for now. Once our other urgent issues are over, we are going to introduce these all to easy portable any MCU. Just that it might take some time.
We can help any issues you enter into.. Even while merging this..
Comparing two codes may take time, I'll try to fix the bug by porting feature/esp_as_mcu_host branch in a few days! thank you.
After the host completes the WiFi connection, occasionally the spi data cannot be received (the data is all 0x00),In fact, the data exchange of SPI is not stopped, it is always in progress, but the data received is invalid!!
I have found that this problem occurs after the occasional power on. If there are no problems at the beginning of the startup, then it is always normal, no matter how large the load test is normal.
The received data is not always 0x00, but has 0xF7 in the second byte(This is also true when spi communication is normal).
When go wrong, i set a breakpoint at this location in the image below and it never enters!! (spi_drv.c process_rx_task)