Hard fault using C40_ip baremetal

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Hard fault using C40_ip baremetal

540 Views
vmhb
Contributor III

I am trying to use an embedded flash sector to store and retrieve configuration data. Using a S32K3x4EVB-Q172 initially I tried to use the C40_Ip driver to read and write the last code sector C40_CODE_ARRAY_0_BLOCK_3_S511, sector 527 at address 0x007FE000. However when attempt to access even read this block I see a hard fault. Switching to using the C40_CODE_ARRAY_0_BLOCK_2_S256 I can seem to read the data on occasion but get random hard faults, particularly from cold start, or if I attempt to erase and write. As these blocks are not used by the running code why do these hard faults occur?

I see there are a number of posts that may be related to this issue but none of them helped to fix the my issue. One in particular suggested relocating the erase and write functions to ram. However this did not even compile for me, even after adding the missing bracket.

Solved: S32K344 C40 IP Hardware Fault Problem - NXP Community

Any suggestions?

 

 

Labels (1)
0 Kudos
Reply
3 Replies

512 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @vmhb,

danielmartynek_2-1709730536261.png

 

danielmartynek_1-1709730485054.png

 

What kind of fault exception do you get when you read C40_CODE_ARRAY_0_BLOCK_2_S256?

Can you read Configurable Fault Status Register (CSFR)?

 

If the code is in Block 0 and you reprogram Block 2, there is no need to have the driver in the SRAM.

Unless the code in Block 0 (this includes Interrupt routines) reads some data from Block 2.

 

Regards,

Daniel

 

 

 

0 Kudos
Reply

508 Views
vmhb
Contributor III

Daniel,

Thank you for getting back to me. From trial and error I managed find that C40_CODE_ARRAY_0_BLOCK_3_S500 worked for me so have been using that. Thanks to you I now understand why.

The hard exceptions seemed related to cache data flushes, which I did not investigate thoroughly. I found that if I disabled the C40_Ip driver option Mem Synchronize Cache the issue went away, although it did raise a concern over data integrity. Is this an acceptable approach or should I go back and look more closely at the exception?

The last issue I was having was that even though the block chosen is near the end of the flash, reprogramming via a debugging session could on occasion erase the block, even though the code size is relatively small. Why only on occasion I have no idea. However there are some settings in the PEmicro tab, under Advanced Options which allow you to specify Non-Volatile Memory Preservation ranges. Adding my flash sector appears to have stopped the sector from being erased.

Thank you again for your insight 

Simon

Tags (1)
0 Kudos
Reply

492 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Simon,

Since the faults are sporadic and random, it is difficult to explain it.

I would recommend analyzing the faults.

The cache invalidation is application-dependent.

danielmartynek_0-1709804471043.png

 

The debugger use a PEMicro proprietary algorithm, you should get more information from the PEMicro support. But since there is the option to preserve certain memory areas, I would use that.

 

Regards,

Daniel

 

0 Kudos
Reply