Hello, I am using the S32K146 chip, and I encounter a HardError feedback when trying to read the contents of PFlash in the code loaded into FlexNVM.
It's strange that this issue is reproducible on some machines but not on others.
The specific code is as follows:
#define UPD_PFLAG_ADRRESS (0x000F0000)
uint8_t readFlag()
{
return (*(volatile uint8_t *)UPD_PFLAG_ADRRESS); //There is a HardError
}
Firstly, I would like to know if this error is caused by the limitation indicated in the diagram below.
#Table 36-30. Allowed simultaneous memory operations in [S32K-RM.pdf] datashee
If so, I attempted to move this code from FlexNVM to SRAM, but the issue still occurs.
Could you help me analyze the reason?
The specific code is as follows:
START_FUNCTION_DECLARATION_RAMSECTION
uint8_t readFlag()
{
return (*(volatile uint8_t *)UPD_PFLAG_ADRRESS); //There is also a HardError
} END_FUNCTION_DECLARATION_RAMSECTION
Solved! Go to Solution.
》The Erase Flash Sector command does the verification too.
Sorry for the late reply.
I agree with your view, and there is also an error verification in the Erase operation.
I will reorganize my process of writing to Flash to ensure that every step of the entire writing process is checked and retried.
Thank you very much for your assistance. I am closing this ticket.
Regards,
Fanjialin
Hello @danielmartynek
Thank you very much for your answer to Q1234, which has been very helpful for me to understand the S32 read and write operations.
I believe I have found the cause of the issue. Could you please confirm if my understanding is correct?
In simple terms, when rewriting Flash content, the following steps should be taken:
Due to missing step 2, there is a certain probability (although low, so it only occurs on some machines) that writing without complete erasure can put the Flash into an abnormal state. Subsequently, attempting to read it again will result in a HardError and the system will fail to start.
Hi @FanJialin
The Erase Flash Sector command does the verification too.
Did you read the error status of the FLASH_DRV_EraseSector.
But yes, it can be verified further using the Verify Section command, refer to the S32K1xx Safety Manual.
Regards,
Daniel
》The Erase Flash Sector command does the verification too.
Sorry for the late reply.
I agree with your view, and there is also an error verification in the Erase operation.
I will reorganize my process of writing to Flash to ensure that every step of the entire writing process is checked and retried.
Thank you very much for your assistance. I am closing this ticket.
Regards,
Fanjialin
Hi @FanJialin,
Do you see FSTAT[RDCOLERR] = 1?
What kind of fault exception is it?
https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447
Regards,
Daniel
@danielmartynek
Thank you for reply.
The error displayed during my debugging using IAR is as shown in the figure, it should be HardFault_Handler.
Sorry,I don't know how to directly observe FSTAT[RDCOLERR] = 1. If the BaseAddress of FSTAT is 0x40020000, the value in the register is as follows.
When reading address 0x000F0000, I also found that for the faulty machines, if I use IAR to observe the content of the Dataflash address, the content is displayed as "-," as shown in the figure below.
For the normal machines, if I use IAR to observe the content of the Dataflash address, the content is not displayed as "-", as shown in the figure below.
Hello @FanJialin,
The FSTAT register is at 0x40020080
The screenshot you posted does not show that.
I don't use IAR, so I don't know what peripherals register view is there.
What is the value in the Cortex M4 Configurable Fault Status Register (CSFR)?
In general, the DFlash is a flash block that can be read while other flash block is read/programmed.
However, there is just one crossbar switch slave port for the flash controler. Either DFlash or PFlash can be read at a time.
Have you tried disabling/masking interrupts before the flash operation?
The vector table and the interrupt routines must not be in the flash that is being programmed.
Also, the ISRs must not access any data in that block.
Regards,
Daniel
Hello @danielmartynek
Thanks for your reply.Could you please help me further confirm the following questions?
Q1:
》The FSTAT register is at 0x40020080
Sorry,I don't understand.
As the screenshot,the base address is 4002_0000h,and the offset is 0h(Reset value is 80h).
So The FSTAT register is at 0x40020000,not 0x40020080.
Q2:
》What is the value in the Cortex M4 Configurable Fault Status Register (CSFR)?
Sorry,I can't find [CSFR] description in the datasheet.
Can you tell me how to confirm the value of [CSFR]?
Q3:
》In general, the DFlash is a flash block that can be read while other flash block is read/programmed.
》However, there is just one core that can access a single block at a time.
In that case,I still don't understand what kind of operation the "NG" marked in the red circle in the diagram prohibits.
Could you further explain it to me?
Q4:
》Have you tried disabling/masking interrupts before the flash operation?
Does this restriction only refer to write operations?Is it necessary before flash read operation?
Hello @FanJialin,
1.
I'm sorry, you are right. So, the RDCOLERR is not detected during the flash operation then.
2.
CFSR is a core register:
https://developer.arm.com/documentation/ddi0439/b/System-Control/Register-summary
3.
The table is a bit confusing in this regard.
It does not prohibit reading DFlash while PFlash is read.
But practically either the CM4 core or DMA (not both at the same time, crossbar arbitration) can access just DFlash or PFlash at a time via the Flash controller.
However, while the flash controller programs/erases PFlash, the core/DMA can read DFlash, this is marked as OK in the table.
4.
It applies to write (program/erase) operations only. Becasue these operations are done by the flash controller. So, while the flash controller is performing operations at the block, the core / DMA must not access the block.
Regards,
Daniel