I ask what state the MCU is in and what cases occur in the following situations.
What's interesting is that if I run a specific function with Over(Trace32), the issue occurs, but when I run it with Step(Trace32), the issue does not occur.
(Power is being supplied to the MCU normally.)
Hello all
We are currently facing the same kind of issue on our project. CRC and C40 modules are not used, however everything else that is described in this topic is valid in our case.
@kjy106906 , have you solved your issue ?
Edit: @danielmartynek , since this topic, have you ever heard of this kind of issue that has been resolved ?
Thank for your answers
Hi @kjy106906,
You wrote: "Strangely, even if I add a few lines of unnecessary code (adding a while statement for debugging, adding a global variable, etc.), the issue does not reproduce."
If you write registers or an sram memory, can you read it back so that all the operations are properly serialized?
RM, rev.8, Section 3.8 Serialization of memory operations.
Regards,
Daniel
Thank you @danielmartynek
I'm also using the C40 library. (C40_Ip_Read)
However, Error is not returned, ( Success is returned.)
When you read the DFlash, do you use the driver?
Because the driver checks for errors:
Thank you,
Daniel
Thank you @danielmartynek
Sharing the entire project is not possible due to company security reasons.
Even if I share my elf, it currently works on my board.
Testing may not be possible in your environment.
It is also not possible to share the simplified elf.
Strangely, even if I add a few lines of unnecessary code (adding a while statement for debugging, adding a global variable, etc.), the issue does not reproduce.
Currently, this issue has occurred in 5 BMS boards.
It's all related to Dataflash.
Could the above phenomenon occur due to dataflash area being broken or other errors?
Hi @kjy106906,
I would like to test it on my side.
Can you share the project?
Or preferably a simplified version with .elf that can reproduce the issue?
If you don't want to share it here, create a ticket.
Thank you,
Daniel
Thank you @danielmartynek
I am currently using Vector Microsar
The MCU does not enter any Os Hal Fault (Exception).
If an MCU Exception is entered, I think I will see the MCU jumping to the corresponding code in the debugger, but currently a Bus error is output in Trace32.
Therefore, it seems that an exception did not occur.
If there are any more points to check, let me know.
Neither Reset_b nor VDD_HA_A fall to Low.
This issue causes infinite SBC reset in BMS-only state without Trace32. Because that issue occurs in Dataflash Init, the MCU does not operate and an infinite reset of the SBC occurs.
So it's not a lauterbach issue either.
It's an important issue for us. Please let me know if there are any more points to check.
Hello @kjy106906,
So, I understand the core does not detect any fault exception, it does not go to the HardFault_Handler().
Can you monitor the reset_b pin? Is the application running?
If so, it might be a lauterbach issue.
BR, Daniel
Thank you
Even if I set a break on the error handler, the break does not occur and the MCU enters the corresponding state.
I wonder what state the MCU is in and the reason for entering that state.
Hi @kjy106906,
Please find more information about the fault exception.
Refer to these documents:
https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447
Read Configurable Fault Status Register (CSFR) and Bus Fault Address Register (BFAR) if BFARVALID = 1. You should be able to find the PC address of the fault instruction on the stack.
Regards,
Daniel
Thank you always @danielmartynek
That function is not an RTD function but a simple calculation function.
An issue occurs when calculating the CRC of C40 read data at a specific address.
This occurs when executing the CRC calculation function, not when reading.
MCU: S32K312, RTD version: 2.0.0
I wonder what state the MCU is in and the reason for entering that state.
Hello @kjy106906,
Can you be more specific?
What function do you step over here?
Can you also specify the MCU and RTD version if you use it?
Thank you,
BR, Daniel
Hello,
We were finally able to identify the root cause of the issue on our side.
It was linked to NXP errata ERR052460, related to branch speculation. The following code snippet corrects the behavior.
// NXP ERR052460 Workaround: Cortex-M7: A hang scenario can occur when a reserved read locked memory region is accessed by application cores
*((uint32_t*) 0x402AC0F0) = 0x1CB0499Du;
*((uint32_t*) 0x402AC0F0) = 0xB9920D38u;I’m not sure whether this is the exact same root cause on your side (I’m not from NXP and it seems they won’t respond anyway), but it’s worth checking.
The same question were you able to find the root cause?
This issue is also observed with size optimizations and goes away if no optimization is used.
@Palacni Thank you very much for your prompt reply. Unfortunately on my derivate there is another peripheral at the location cited by errata to enable user access. I've asked NXP for errata of my relatively new derivate .......... . . .
It works when any one of the following is used,
- Disable the optimizations (-O0)
- Use SRAM of another domain on the SoC
- Disable the Instruction cache
- Stepping in via debugger