Issue regarding the failure of memory-mapped functionality on STM32N657X0H3Q
I currently have two boards equipped with different specific models of N6, namely STM32N647X0H3Q and STM32N657X0H3Q. I have an IDE project for testing the memory-mapped functions of each of these two chips.
The problem lies in that this project can be implemented on the STM32N647X0H3Q in a manner similar to:
data = *(volatile uint8_t *)0x70100000;Such code reads the content from the external FLASH. However, on the STM32N657X0H3Q, it is impossible to read. The specific manifestation is that when I run this line of code in the debug mode, the program directly jumps to
void SysTick_Handler(void)and the debugging connection is disconnected, as shown in the following figure.
I have wondered whether it was an issue with the external FLASH soldering, or a problem with the PCB traces (my two circuit boards were not produced on the same PCB. The circuit board with STM32N647X0H3Q was purchased from the internet, while the one with STM32N657X0H3Q was designed based on the schematic diagram of the N647 board). However,... My external FLASH is MX25UM25645GXDI00 and it communicates via XSPI2. Then I did not use memory_mapped to access the internal data of the flash. Therefore, I conducted simulations on the following code.
uint32_t test_address = 0x01000000; // 16MBlocation
uint8_t write_buf[16] =
{
0xA5, 0x5A, 0x11, 0x22,
0x33, 0x44, 0x55, 0x66,
0x77, 0x88, 0x99, 0xAA,
0xBB, 0xCC, 0xDD, 0xEE
};
uint8_t read_buf[16] =
{
0
};
NORFlash_StatusTypeDef erase_status;
NORFlash_StatusTypeDef write_status;
NORFlash_XSPI_StatusTypeDef read_status;
/*
* 1. Erase one sector
*/
erase_status =
NORFlash_EraseSector(
NORFlashObject,
test_address,
NORFlashObject->Information.SectorSize
);
volatile NORFlash_StatusTypeDef debug_erase_status =
erase_status;
/*
* 2. Write 16 bytes
*/
write_status =
NORFlash_Write(
NORFlashObject,
test_address,
write_buf,
sizeof(write_buf)
);
volatile NORFlash_StatusTypeDef debug_write_status =
write_status;
// HAL_Delay(500);
/*
* 3. Read back
* OPI 8D8D8D Read Command = 0xEE
*/
read_status =
NORFlash_XSPI_CommandSendAddressReadData(
&(NORFlashObject->XSPIObject),
NORFlashObject->Command.MapRead.Command,
test_address,
read_buf,
sizeof(read_buf)
);
volatile NORFlash_XSPI_StatusTypeDef debug_read_status =
read_status;
/*
* 4. Compare result
*/
volatile uint8_t debug_read0 = read_buf[0];
volatile uint8_t debug_read1 = read_buf[1];
volatile uint8_t debug_read2 = read_buf[2];
volatile uint8_t debug_read3 = read_buf[3];
volatile uint8_t debug_read4 = read_buf[4];
volatile uint8_t debug_read5 = read_buf[5];
volatile uint8_t debug_read6 = read_buf[6];
volatile uint8_t debug_read7 = read_buf[7];
uint8_t verify_result = 1;
for(uint32_t i = 0; i < sizeof(write_buf); i++)
{
if(write_buf[i] != read_buf[i])
{
verify_result = 0;
break;
}
}
volatile uint8_t debug_verify_result = verify_result;This code performs erasure, writing and reading operations by directly controlling the XSPI communication. By writing specific values at the designated location and then reading them, it can be proven that communication with the external FLASH memory is possible without being in the memory-mapped mode. The execution result of the code is as follows.
Obviously, the data in read_buf is the same as that in write_buf. I think this would prove that there is no problem with the circuit and no issue with the components. If there is a better method, or if there is anything wrong with my verification method, please point it out. Thank you.
Then I asked GPT, and GPT said it might be a problem with the continuous reading timing in the memory-mapped mode. I also tried changing the configuration from 8D8D8D to 1S1S1S, and changing the clock frequency to 25 MHz. But the problem remained the same.
I also considered that it might be an illegal access to the memory address. Therefore, I changed the access address as follows.
uint8_t data;
data = *(volatile uint8_t *)0x00000000;
Then I conducted the debug, and the result is shown in the following figure. The debug directly jumped to the HardFault_Handler and did not disconnect the simulation connection. So I believe that when accessing the external flash through memory mapping, it is not accessing an illegal address. Because it jumped to SysTick_Handler and disconnected the simulation link. I still don't understand what might have happened inside the microcontroller in such a situation.
In summary, I would like to know exactly what went wrong that allowed my engineering code to successfully retrieve the value from the external flash on the original STM32N647 board that I purchased, but on my own-designed STM32N657 board, the debugging connection was disconnected and it displayed that it had jumped to the systick_handler.
