ci: fix one ut issue when using Wrover-B module with newer ver of PSRAM

The workaround for PSRAM that will occupy an SPI bus is enabled only when:

1. used on 32MBit ver 0 PSRAM.
2. work at 80MHz.

The test used to only check 32MBit by the config option, but for PSRAM
on Wrover-B module seems to use a newer version of 32MBit PSRAM.  So it
expects the workaround to be enabled, but actually not.

This commit split the unit test into two parts:

1. check all SPI buses are available, for all configs except psram_hspi
and psram_vspi, run on regular runners (including Wrover and Wrover-B).
a hidden option is enabled so that the compiler knows it's not building
psram_hspi or psram_vspi.

2. check the specified bus are acquired, for config psram_hspi and
psram_vspi. This only run on special runner (legacy Wrover module).
This commit is contained in:
Michael (XIAO Xufeng)
2019-10-31 12:00:46 +08:00
committed by bot
parent 4c4b1da7e7
commit f54cab62a2
7 changed files with 70 additions and 21 deletions

View File

@@ -610,6 +610,12 @@ psram_size_t psram_get_size()
}
}
//used in UT only
bool psram_is_32mbit_ver0(void)
{
return PSRAM_IS_32MBIT_VER0(s_psram_id);
}
/*
* Psram mode init will overwrite original flash speed mode, so that it is possible to change psram and flash speed after OTA.
* Flash read mode(QIO/QOUT/DIO/DOUT) will not be changed in app bin. It is decided by bootloader, OTA can not change this mode.
@@ -720,9 +726,13 @@ esp_err_t IRAM_ATTR psram_enable(psram_cache_mode_t mode, psram_vaddr_mode_t vad
return ESP_FAIL;
}
if (PSRAM_IS_32MBIT_VER0(s_psram_id)) {
if (psram_is_32mbit_ver0()) {
s_clk_mode = PSRAM_CLK_MODE_DCLK;
if (mode == PSRAM_CACHE_F80M_S80M) {
#ifdef CONFIG_SPIRAM_OCCUPY_NO_HOST
ESP_EARLY_LOGE(TAG, "This version of PSRAM needs to claim an extra SPI peripheral at 80MHz. Please either: choose lower frequency by SPIRAM_SPEED_, or select one SPI peripheral it by SPIRAM_OCCUPY_*SPI_HOST in the menuconfig.");
abort();
#else
/* note: If the third mode(80Mhz+80Mhz) is enabled for 32MBit 1V8 psram, one of HSPI/VSPI port will be
occupied by the system (according to kconfig).
Application code should never touch HSPI/VSPI hardware in this case. We try to stop applications
@@ -746,6 +756,7 @@ esp_err_t IRAM_ATTR psram_enable(psram_cache_mode_t mode, psram_vaddr_mode_t vad
break;
}
}
#endif
}
} else {
// For other psram, we don't need any extra clock cycles after cs get back to high level