Frequent access to hard fault interrupts

[FAR1234]

Dear NXP experts,
My Toolchain: S32DS v3.4, S32SDK_S32K1XX_STM_4.0.3, SEGGER J-Link GDB Server V7.98a;
MCU:S32K142W;
Problem description:

As shown in the figure above, move LedToggle() from line 678 to line 659, build it, debug it, and trigger a Hard fault when stepping on "FTM_DRV_InitInputCapture()" from line 286 in the figure below.

Key data obtained after triggering a Hard fault:

Let me add the process of restoring a Hard Fault:
The first method:
Use J-Flash V7.98a to erase the entire code of S32K142W chip, then enter S32DS V3.4 environment for debugging, and it will be restored to normal. This method has been tested repeatedly.

The second method:
Firstly, change Optimization Level: None (- O0) to Optimization Level: Optimize (- O1), debug again, and restore normal operation without entering Hard Fault again;

Then, based on keeping the code as it is, change the Optimization Level: Optimize (- O1) back to Optimization Level: None (- O0), debug again, run normally, and no longer enter Hard Fault;

Finally, at Optimization Level: None (- O0), the difference between entering Hard Fault and not entering Hard Fault was compared between the two Build generated files. The conclusion was that there was no difference (as shown in the figure below), but the results of the two debug attempts were different.

We compared the debugging information in the Console window between entering Hard Fault (left file) and not entering Hard Fault (right file) during these two debugs, as shown in the following figure:

Can you help me analyze why the Hard Fault was triggered?

Best regards.

LF

[danielmartynek]

Hello @FAR1234,

I see that the behavior depends on the optimization level.

Please note that NXP guarantees the functionality of the SDK only when the compiler options are configured according to the SDK release notes. The SDK was developed and tested under those specific settings.

Could you adjust your compiler options to match the configuration outlined in the release notes?

Some of the screenshots you provided are of very low quality, making them difficult to read. If the issue persists after updating the settings, please share higher-quality screenshots. You can upload them as a .zip file if needed.

Lastly, I recommend using your company email address for future support cases instead of a personal one.

Regards,

Daniel

[FAR1234]

Hi @danielmartynek 

I am glad to receive your reply.

Here is the Compiler/Linker options information for my project:

Note:The options in blue font are consistent with the requirements of "S32 SDK Release Notes Version 4.0.3 RTM";
The option in black font is unique to me;

GCC Compiler Options of My Project

-std=c99

-DCPU_S32K142W

-DDEV_ERROR_DETECT

-I"E:\Git_Local\litro_etc_project_app\Software\App".......Ignore other including paths.........

-O1

-g

-Wall

-Wextra

-c

-fmessage-length=0

-ffunction-sections

-fdata-sections

-fno-common

-Wunused

-mcpu=cortex-m4

-mthumb

-mno-unaligned-access

-mfloat-abi=hard

-mfpu=fpv4-sp-d16

-specs=nosys.specs --sysroot="D:\NXP\S32DS.3.4\eclipse\../S32DS/build_tools/gcc_b1620/gcc-6.3-arm32-eabi/arm-none-eabi/newlib"

GCC Assembler Options of My Project

-c

-I"E:\Git_Local\litro_etc_project_app\Software\App"

 -x assembler-with-cpp

-DSTART_FROM_FLASH

-g

-mcpu=cortex-m4

-mthumb

-mfloat-abi=hard

-mfpu=fpv4-sp-d16

-specs=nosys.specs

--sysroot="D:\NXP\S32DS.3.4\eclipse\../S32DS/build_tools/gcc_b1620/gcc-6.3-arm32-eabi/arm-none-eabi/newlib"

GCC Linker Options of My Project

-L"D:\NXP\S32DS.3.4\eclipse\../S32DS/software/AMMCLIB_v1.1.22/S32K14x_AMMCLIB_v1.1.22//lib/s32ds_arm32"

-T "E:\Git_Local\litro_etc_project_app\Software\Bsw\MCU_Drivers\FS32K142W\devices\S32K142W\linker\gcc\S32K142W_32_flash.ld"

-Wl,-Map,"litro_etc_project_app_New.map"

-Xlinker --gc-sections

-n

-mcpu=cortex-m4 -mthumb

-mfloat-abi=hard

-mfpu=fpv4-sp-d16

-specs=nosys.specs

--sysroot="D:\NXP\S32DS.3.4\eclipse\../S32DS/build_tools/gcc_b1620/gcc-6.3-arm32-eabi/arm-none-eabi/newlib"

 

To summarize, my project was created through the "S32DS Project from Example" method. The GCC Compiler Options, GCC Assembler Options and GCC Linker Options
are still different from "S32 SDK Release Notes Version 4.0.3 RTM". Does this have any impact?

Best Regards

LF

 

[danielmartynek]

Hello LF,

The thing is that we cannot guarantee the correct functionality of the RTD if compiler options differ from those specified in the release notes. The RTD has been validated only with the exact compiler flags provided in the official documentation. If you choose to use custom compiler flags, you are responsible for verifying the functionality of the drivers under those conditions.

Do you observe the issue even when the compiler options are aligned with those specified in the release notes?

Regards,

Daniel

[FAR1234]

Hi @danielmartynek 

I am glad to receive your reply.

When my compilation options are the same as those provided in "S32 SDK Release Notes Version 4.0.3 RTM", there is still a situation of entering Hardfault, which has not been improved.

I have identified a key issue, which is that when a problem occurs, I use J-Flash V7.98a to read data from the chip's Flash and compare it with the Bin file generated by the project. I found that there is a section of content with a length of 248 bytes, all of which are 0xFF, which is different from the content of the Bin file.As shown in the figure below.

Use J-Flash V7.98a to erase the entire code of S32K142W chip, then enter S32DS V3.4 environment for debugging, and it will be restored to normal. This method has been tested repeatedly.

Why is there a section of code downloaded through Debug that is incorrect ?

LF

[danielmartynek]

Hi @FAR1234,

I'm not sure I fully understand the situation.

Just to clarify:

• You programmed the binary using J-Flash V7.98a, but after programming, there is a 248-byte section in Flash that remains erased (filled with 0xFF), which does not match the content of the binary.
• Does J-Flash report any errors or warnings during the programming process?
• When you program the MCU using S32DS V3.4, the issue does not occur, and the application runs normally.

If so, you may consider contacting SEGGER, JFlash is not an NXP product.

Regards,

Daniel

[FAR1234]

Hi @danielmartynek 

I am glad to receive your reply.

The process you mentioned is not what I meant to express.

I will reorganize my operation process:

Step one,
In the S32DS V3.4 environment, delete a test code and then execute Clean ->Build ->Debug ->Resume. The program immediately freezes at HardFault_CHandler().
Next, stop Debug and exit the S32DS V3.4 environment. Using J-Flash V7.98a to connect to the target chip, only the operation of reading the program in the chip is performed. Comparing the read program with the content of the Bin file, it is found that 248 bytes of the program in the chip are filled with 0xFF, which is different from the program in the Bin file. Please refer to the following figure for details.

The second step,
Connect the target chip using J-Flash V7.98a, perform only the "Erase Chip" operation, and disconnect the connection.

Step three,
In S32DS V3.4 environment, execute Debug ->Resume to restore the program to normal.

Best Regards

LF

[danielmartynek]

Hi @FAR1234,

Are the erased bytes located at 0x5000?

What is at this address in the linker file?

Do you write to the flash configuration field at 0x400?

Does the S32DS reports any issues when it programs the MCU incorrectly?

Can you share the log?

Please note that the debugger in the S32DS is a plubin from SEGGER if you use J-link.

Regards,

Daniel

[FAR1234]

Hi @danielmartynek 

I am glad to receive your reply.

In response to your question, we would like to provide the following response:

1), Are the erased bytes located at 0x5000?

I am performing a full erase, specifically from 0000_0000 to 0003_FFFF, and from 1000_0000 to 1000_FFFF.

2), What is at this address in the linker file?

I didn't understand what you meant, but I provided my link file.
Please see what I added at the bottom: Content of file "S32K142W_32_flash.ld"

3), Do you write to the flash configuration field at 0x400?

I have never written the flash configuration field at 0x400.

4), Does the S32DS reports any issues when it programs the MCU incorrectly?

I didn't notice any errors.

5), Can you share the log?

Please refer to the attachment (Hardfault pictures. rar), where "Image 5. png", "Image 6. png", "Image 7. png", and "Image 8. png" are related to log information.

Content of file "S32K142W_32_flash.ld":

/* Entry Point */
ENTRY(Reset_Handler)

HEAP_SIZE = DEFINED(__heap_size__) ? __heap_size__ : 0x00000400;
STACK_SIZE = DEFINED(__stack_size__) ? __stack_size__ : 0x00001000;

/* If symbol __flash_vector_table__=1 is defined at link time
* the interrupt vector will not be copied to RAM.
* Warning: Using the interrupt vector from Flash will not allow
* INT_SYS_InstallHandler because the section is Read Only.
*/
M_VECTOR_RAM_SIZE = DEFINED(__flash_vector_table__) ? 0x0 : 0x0400;

/* Specify the memory areas */
MEMORY
{
/* Flash */
m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0003FBF0

/* SRAM_L */
m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00004000

/* SRAM_U */
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00003000
}

/* Define output sections */
SECTIONS
{
/* The startup code goes first into internal flash */
.interrupts :
{
__VECTOR_TABLE = .;
__interrupts_start__ = .;
. = ALIGN(4);
KEEP(*(.isr_vector)) /* Startup code */
__interrupts_end__ = .;
. = ALIGN(4);
} > m_interrupts

.flash_config :
{
. = ALIGN(4);
KEEP(*(.FlashConfig)) /* Flash Configuration Field (FCF) */
. = ALIGN(4);
} > m_flash_config

/* The program code and other data goes into internal flash */
.text :
{
. = ALIGN(4);
*(.text) /* .text sections (code) */
*(.text*) /* .text* sections (code) */
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
*(.init) /* section used in crti.o files */
*(.fini) /* section used in crti.o files */
*(.eh_frame) /* section used in crtbegin.o files */
. = ALIGN(4);
} > m_text

/* Section used by the libgcc.a library for fvp4 */
.ARM :
{
__exidx_start = .;
*(.ARM.exidx*)
__exidx_end = .;
} > m_text

/* Sections used by startup for data initialization. */
.init_table :
{
. = ALIGN(4);
__COPY_TABLE = .;
KEEP(*(.init_table))
} > m_text
.zero_table :
{
. = ALIGN(4);
__ZERO_TABLE = .;
KEEP(*(.zero_table))
} > m_text

__etext = .; /* Define a global symbol at end of code. */
__DATA_ROM = .; /* Symbol is used by startup for data initialization. */

.interrupts_ram :
{
. = ALIGN(4);
__VECTOR_RAM__ = .;
__RAM_START = .;
__interrupts_ram_start__ = .; /* Create a global symbol at data start. */
*(.m_interrupts_ram) /* This is a user defined section. */
. += M_VECTOR_RAM_SIZE;
. = ALIGN(4);
__interrupts_ram_end__ = .; /* Define a global symbol at data end. */
} > m_data

__VECTOR_RAM = DEFINED(__flash_vector_table__) ? ORIGIN(m_interrupts) : __VECTOR_RAM__ ;
__RAM_VECTOR_TABLE_SIZE = DEFINED(__flash_vector_table__) ? 0x0 : (__interrupts_ram_end__ - __interrupts_ram_start__) ;
__VECTOR_TABLE_COPY_END = __VECTOR_TABLE + __RAM_VECTOR_TABLE_SIZE;

.data : AT(__DATA_ROM)
{
. = ALIGN(4);
__DATA_RAM = .;
__data_start__ = .; /* Create a global symbol at data start. */
*(.data) /* .data sections */
*(.data*) /* .data* sections */
. = ALIGN(4);
__data_end__ = .; /* Define a global symbol at data end. */
} > m_data

__DATA_END = __DATA_ROM + (__data_end__ - __data_start__);
__CODE_ROM = __DATA_END; /* Symbol is used by code initialization. */

.code : AT(__CODE_ROM)
{
. = ALIGN(4);
__CODE_RAM = .;
__code_start__ = .; /* Create a global symbol at code start. */
__code_ram_start__ = .;
*(.code_ram) /* Custom section for storing code in RAM */
. = ALIGN(4);
__code_end__ = .; /* Define a global symbol at code end. */
__code_ram_end__ = .;
} > m_data

__CODE_END = __CODE_ROM + (__code_end__ - __code_start__);
__CUSTOM_ROM = __CODE_END;

/* Custom Section Block that can be used to place data at absolute address. */
/* Use __attribute__((section (".customSection"))) to place data here. */
.customSectionBlock ORIGIN(m_data_2) : AT(__CUSTOM_ROM)
{
__CUSTOM_RAM = .;
__customSectionStart = .;
__customSection_start__ = .;
KEEP(*(.customSection)) /* Keep section even if not referenced. */
__customSection_end__ = .;
} > m_data_2
__CUSTOM_END = __CUSTOM_ROM + (__customSection_end__ - __customSection_start__);
__rom_end = __CUSTOM_END;

/* Uninitialized data section. */
.bss :
{
/* This is used by the startup in order to initialize the .bss section. */
. = ALIGN(4);
__BSS_START = .;
__bss_start__ = .;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
__bss_end__ = .;
__BSS_END = .;
} > m_data_2

/* Put heap section after the program data */
.heap :
{
. = ALIGN(8);
__end__ = .;
__heap_start__ = .;
PROVIDE(end = .);
PROVIDE(_end = .);
PROVIDE(__end = .);
__HeapBase = .;
. += HEAP_SIZE;
__HeapLimit = .;
__heap_limit = .;
__heap_end__ = .;
} > m_data_2

/* Initializes stack on the end of block */
__StackTop = ORIGIN(m_data_2) + LENGTH(m_data_2);
__StackLimit = __StackTop - STACK_SIZE;
PROVIDE(__stack = __StackTop);
__RAM_END = __StackTop;

.stack __StackLimit :
{
. = ALIGN(8);
__stack_start__ = .;
. += STACK_SIZE;
__stack_end__ = .;
} > m_data_2

.ARM.attributes 0 : { *(.ARM.attributes) }

/* Memory validation */
ASSERT(__rom_end <= (ORIGIN(m_text) + LENGTH(m_text)), "Region m_text overflowed!")

ASSERT(__StackLimit >= __HeapLimit, "region m_data_2 overflowed with stack and heap")
}

Best regards

LF

[danielmartynek]

Hi @FAR1234,

Q1. You showed a dump of some memory, what memory is it? What is the address of it?

Q2. Can you also show the .map file at the address range from Q1?

Q3. Can you read the bytes at 0x400 - 0x40F?

Thank you,

Daniel

[FAR1234 · Accepted solution]

Hi @danielmartynek 
I have found the reason, it is a compatibility issue between S32DS v3.4 and Segger Jlink version. After upgrading to the latter version, the problem was resolved.

best regards

LF

[FAR1234]

Add attachment.