Dear NXP Support/NXP Expert,
I am developing a bootloader for S32K341 processor.
I have started from an example (Mem_InFls_Example_S32K344).
To start, I have modified the memap files in order to put in RAM all the function involved to the pflash job and It worked, BUT I want to work with the original generated files (with an exception of c40 files where, on my understanding, It is necessary to change the pragma declaration).
So, I have enabled Mem load access code on job start
the erase and write address are placed in the end of the ram zone
- int_sram : ORIGIN = 0x20400000, LENGTH = 0x00007F00.
1) Is that correct? Or I have to put these pointers in other zone?
Below you can find the ramcode section from the map file:
2) Am I missing some function?
The issue is an hard fault handler, it is started from:
- 0x40d2e5
: b.n 0x40d300 ; - 0x40d3f3
: b.n 0x40d40e ;
basically near the "jump" to the flash driver.
3) Any idea?
I am a little bit stucked.
Thanks a lot,
Ciancio
Hi @il_ciancio,
Great to hear that it helped
This issue likely occurs because the core writes data to SRAM, which is affected by the data cache, if the core would read the data, there would be no issue. However, when the core tries to execute code from that same memory region, it relies on the instruction cache. If the instruction cache hasn’t been properly invalidated or updated, the core may end up fetching uninitialized instructions — executing 0x00 bytes instead of the actual code with 0x1 at LSB.
Regards,
Daniel
- Remove MPU_ENABLE: this solution doesn't work, but the sram area is cachable, maybe I have to try with a no cachable area.
- Enable Mem clean cache After Load Access Code: with this solution and the same pointer and the MPU_ENABLE the code works! You get the point, great work, thanks a lot!
About the thumb addresses, I am a little bit confused, because the macro MEM_43_INFLS_AC_CALL is compiled with an or with ARM_FAR_CALL2THUMB_CODE_BIT0_U32, so the jump itself should work. Maybe inside the flashdriver there is this issue?
By the way, as I wrote, enabling the cache the code is working.
I will wait If you have other comments on MEM_43_INFLS_AC_CALL and I'll close the ticket.
Thanks a lot and again, great work!
Ciancio
1. Go to the properties of the project and remove this symbol.
2. This INVSTATE fault is caused by branching to to a non-thumb address - a thumb address has the least significant bit set to 1. And this can be potentially caused by the cache - the core branches to whatever is in the cache.
Regards,
Daniel
I will try both ways, just some questions:
- is there an api to disable MPU?
- This can also be (potentially) caused by the Cache (managed by the MPU). ->just for my understanding of the micro, how did you come to this conclusion? do you have any references to this error?
thanks a lot and great work!
Ciancio
This can also be (potentially) caused by the Cache (managed by the MPU).
MPU can be disabled in the startup code - so you can easily test it.
However, you can enable the option below to clean the cache.
It is related to this:
Lookin to the data stored in the ram the hard fault start from (MEM_43_INFLS_AC_CALL in Mem_43_INFLS_IPW_Erase):
IR instruction:
0x40dc05
Thanks a lot.
Hi @il_ciancio,
In the fault handler, read the Configurable Fault Status Register (CFSR) to determine the cause of the fault.
Refer to the official ARM documentation for details:
https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/System-control-block/Configu...
If the fault is identified as a MemManage fault, inspect the Memory Protection Unit (MPU) configuration for the memory region at address 0x20407E00.
Thanks for your reply.
This is my configuration and via debugger I can see in the RAM area the the Access Code is loaded. The erase/write pointer are not used by the application.
What can i check?
Thanks
Hi @il_ciancio,
I just tested it with the default Mem_InFls_Example_S32K344 example.
I changed the sector to a BLOCK_0 sector.
#define EXAMPLE_SECTOR_START_ADDR (0x004F0000U)
I saw that these SRAM locations were unused by the application, so I used them:
The code is being copied there:
And the example works as expected.
Can you test it on your side?
Thank you,
Regards,
Daniel