esp32s2: return correct CPU number in esp_cache_err_get_cpuid
This commit is contained in:
parent
c5f664d4ac
commit
66889a7a58
|
@ -45,14 +45,8 @@ void esp_cache_err_int_init(void)
|
|||
intr_matrix_set(core_id, ETS_CACHE_IA_INTR_SOURCE, ETS_MEMACCESS_ERR_INUM);
|
||||
|
||||
// Enable invalid cache access interrupt when the cache is disabled.
|
||||
// When the interrupt happens, we can not determine the CPU where the
|
||||
// invalid cache access has occurred. We enable the interrupt to catch
|
||||
// invalid access on both CPUs, but the interrupt is connected to the
|
||||
// CPU which happens to call this function.
|
||||
// For this reason, panic handler backtrace will not be correct if the
|
||||
// interrupt is connected to PRO CPU and invalid access happens on the APP
|
||||
// CPU.
|
||||
|
||||
// The status bits are cleared first, in case we are restarting after
|
||||
// a cache error has triggered.
|
||||
DPORT_SET_PERI_REG_MASK(EXTMEM_CACHE_DBG_INT_CLR_REG,
|
||||
EXTMEM_MMU_ENTRY_FAULT_INT_CLR |
|
||||
EXTMEM_DCACHE_REJECT_INT_CLR |
|
||||
|
@ -78,7 +72,9 @@ void esp_cache_err_int_init(void)
|
|||
|
||||
int IRAM_ATTR esp_cache_err_get_cpuid(void)
|
||||
{
|
||||
// TODO: The description for this seem to indicate that when cache is not in error
|
||||
// state, return -1.
|
||||
return PRO_CPU_NUM;
|
||||
if (REG_READ(EXTMEM_CACHE_DBG_STATUS0_REG) != 0 ||
|
||||
REG_READ(EXTMEM_CACHE_DBG_STATUS1_REG) != 0) {
|
||||
return PRO_CPU_NUM;
|
||||
}
|
||||
return -1;
|
||||
}
|
||||
|
|
Loading…
Reference in a new issue