Debugging Issue with S32K144 MCU Using SEGGER J-Link and S32DS IDE

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

Debugging Issue with S32K144 MCU Using SEGGER J-Link and S32DS IDE

1,077 Views
Gowtham_768
Contributor I

Sure, Gowtham! Here's a clear and technical version of your question that you can post in a community group (like NXP forums, Stack Overflow, or embedded systems groups):

Hi everyone,

I'm working on S32K144 and currently developing custom MCAL drivers. I'm using the SEGGER J-Link debugger along with S32 Design Studio (S32DS) for development.

While trying to debug my code, I’m encountering a continuous stream of errors and warnings related to register and memory access. Below are the key error messages:

ERROR: Cannot read register 26 (FAULTMASK) while CPU is running  
ERROR: Cannot read register 27 (CONTROL) while CPU is running  
...
ERROR: Cannot read register 64 (FPS31) while CPU is running  
WARNING: Failed to read memory @ address 0xDEADBEEE  

Observations:

  • These errors appear as soon as the target starts running.

  • It seems like the debugger is unable to access system or floating-point registers while the CPU is in execution mode.

  • The memory warning is pointing to an invalid address: 0xDEADBEEE.

Current Setup:

  • MCU: NXP S32K144 (ARM Cortex-M4F)

  • IDE: S32 Design Studio

  • Debugger: SEGGER J-Link (SWD mode, 1 MHz)

  • Application: Bare-metal, developing and testing custom MCAL drivers

  • Debug Mode: Connected via GDB server and flashing/debugging through S32DS

Questions:

  1. Why am I getting these register access errors while the CPU is running?

    • Is there a setting to allow register reads during execution or must the CPU be halted?

  2. What could be the root cause for memory access at 0xDEADBEEE?

    • Is this a common default value used for uninitialized pointers in NXP drivers or MCAL?

  3. Any recommended way to handle these debugger limitations when developing low-level MCAL drivers?

I'd really appreciate help from anyone who has worked with S32K1xx MCUs, MCAL development, or SEGGER J-Link tools. Let me know if you need more logs or setup details.

Thank you

 

Tags (1)
0 Kudos
Reply
1 Reply

995 Views
Julián_AragónM
NXP TechSupport
NXP TechSupport

Hi @Gowtham_768,

Sorry to reply with more answers, but please help me confirm this information:

Is this the first time you are trying to connect to the board, or were you able to debug and connect before?

Are you using S32DS v3.6? If not, which version? Also, please share if you are implementing SDK or RTD drivers, and which version as well.

  1. Why am I getting these register access errors while the CPU is running? Is there a setting to allow register reads during execution or must the CPU be halted?

    The CPU must be halted.
  2. What could be the root cause for memory access at 0xDEADBEEE? Is this a common default value used for uninitialized pointers in NXP drivers or MCAL?

    The 0xDEADBEEE value mainly indicates an error. It's not a standard memory location but rather a value used to indicate that a memory section is uninitialized/has an error. I believe that in your case; it simply states that it cannot connect to the MCU 
  3. Any recommended way to handle these debugger limitations when developing low-level MCAL drivers?

    The first and more obvious thing to say will be to double check that the connection is correct. If you were able to connect before but not now, then there are a couple of things that could be preventing from that:
  • Device was using security features when performing mass erase.
  • Device is secured.
  • Flash Configuration Field was compromised.

Please check the following application note where this issues are detailed described: AN12130: Production Flash Programming Best Practices for S32K1xx MCUs – Application Note

Best regards,
Julián

 

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2141153%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3EDebugging%20Issue%20with%20S32K144%20MCU%20Using%20SEGGER%20J-Link%20and%20S32DS%20IDE%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2141153%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3ESure%2C%20Gowtham!%20Here's%20a%20clear%20and%20technical%20version%20of%20your%20question%20that%20you%20can%20post%20in%20a%20community%20group%20(like%20NXP%20forums%2C%20Stack%20Overflow%2C%20or%20embedded%20systems%20groups)%3A%3C%2FP%3E%3CP%3EHi%20everyone%2C%3C%2FP%3E%3CP%3EI'm%20working%20on%20%3CSTRONG%3ES32K144%3C%2FSTRONG%3E%20and%20currently%20developing%20%3CSTRONG%3Ecustom%20MCAL%20drivers%3C%2FSTRONG%3E.%20I'm%20using%20the%20%3CSTRONG%3ESEGGER%20J-Link%20debugger%3C%2FSTRONG%3E%20along%20with%20%3CSTRONG%3ES32%20Design%20Studio%20(S32DS)%3C%2FSTRONG%3E%20for%20development.%3C%2FP%3E%3CP%3EWhile%20trying%20to%20debug%20my%20code%2C%20I%E2%80%99m%20encountering%20a%20continuous%20stream%20of%20errors%20and%20warnings%20related%20to%20register%20and%20memory%20access.%20Below%20are%20the%20key%20error%20messages%3A%3C%2FP%3E%3CPRE%3EERROR%3A%20Cannot%20read%20register%2026%20(FAULTMASK)%20while%20CPU%20is%20running%20%20%0AERROR%3A%20Cannot%20read%20register%2027%20(CONTROL)%20while%20CPU%20is%20running%20%20%0A...%0AERROR%3A%20Cannot%20read%20register%2064%20(FPS31)%20while%20CPU%20is%20running%20%20%0AWARNING%3A%20Failed%20to%20read%20memory%20%40%20address%200xDEADBEEE%20%20%3C%2FPRE%3E%3CP%3E%3CSTRONG%3EObservations%3A%3C%2FSTRONG%3E%3C%2FP%3E%3CUL%3E%3CLI%3E%3CP%3EThese%20errors%20appear%20as%20soon%20as%20the%20target%20starts%20running.%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3EIt%20seems%20like%20the%20debugger%20is%20unable%20to%20access%20system%20or%20floating-point%20registers%20while%20the%20CPU%20is%20in%20execution%20mode.%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3EThe%20memory%20warning%20is%20pointing%20to%20an%20invalid%20address%3A%200xDEADBEEE.%3C%2FP%3E%3C%2FLI%3E%3C%2FUL%3E%3CP%3E%3CSTRONG%3ECurrent%20Setup%3A%3C%2FSTRONG%3E%3C%2FP%3E%3CUL%3E%3CLI%3E%3CP%3EMCU%3A%20NXP%20S32K144%20(ARM%20Cortex-M4F)%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3EIDE%3A%20S32%20Design%20Studio%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3EDebugger%3A%20SEGGER%20J-Link%20(SWD%20mode%2C%201%20MHz)%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3EApplication%3A%20Bare-metal%2C%20developing%20and%20testing%20custom%20MCAL%20drivers%3C%2FP%3E%3C%2FLI%3E%3CLI%3E%3CP%3EDebug%20Mode%3A%20Connected%20via%20GDB%20server%20and%20flashing%2Fdebugging%20through%20S32DS%3C%2FP%3E%3C%2FLI%3E%3C%2FUL%3E%3CP%3E%3CSTRONG%3EQuestions%3A%3C%2FSTRONG%3E%3C%2FP%3E%3COL%3E%3CLI%3E%3CP%3EWhy%20am%20I%20getting%20these%20register%20access%20errors%20while%20the%20CPU%20is%20running%3F%3C%2FP%3E%3CUL%3E%3CLI%3E%3CP%3EIs%20there%20a%20setting%20to%20allow%20register%20reads%20during%20execution%20or%20must%20the%20CPU%20be%20halted%3F%3C%2FP%3E%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3CLI%3E%3CP%3EWhat%20could%20be%20the%20root%20cause%20for%20memory%20access%20at%200xDEADBEEE%3F%3C%2FP%3E%3CUL%3E%3CLI%3E%3CP%3EIs%20this%20a%20common%20default%20value%20used%20for%20uninitialized%20pointers%20in%20NXP%20drivers%20or%20MCAL%3F%3C%2FP%3E%3C%2FLI%3E%3C%2FUL%3E%3C%2FLI%3E%3CLI%3E%3CP%3EAny%20recommended%20way%20to%20handle%20these%20debugger%20limitations%20when%20developing%20low-level%20MCAL%20drivers%3F%3C%2FP%3E%3C%2FLI%3E%3C%2FOL%3E%3CP%3EI'd%20really%20appreciate%20help%20from%20anyone%20who%20has%20worked%20with%20S32K1xx%20MCUs%2C%20MCAL%20development%2C%20or%20SEGGER%20J-Link%20tools.%20Let%20me%20know%20if%20you%20need%20more%20logs%20or%20setup%20details.%3C%2FP%3E%3CP%3EThank%20you%3C%2FP%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2142977%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20Debugging%20Issue%20with%20S32K144%20MCU%20Using%20SEGGER%20J-Link%20and%20S32DS%20IDE%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2142977%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F253114%22%20target%3D%22_blank%22%3E%40Gowtham_768%3C%2FA%3E%2C%3C%2FP%3E%0A%3CP%3ESorry%20to%20reply%20with%20more%20answers%2C%20but%20please%20help%20me%20confirm%20this%20information%3A%3C%2FP%3E%0A%3CP%3EIs%20this%20the%20first%20time%20you%20are%20trying%20to%20connect%20to%20the%20board%2C%20or%20were%20you%20able%20to%20debug%20and%20connect%20before%3F%3C%2FP%3E%0A%3CP%3EAre%20you%20using%20S32DS%20v3.6%3F%20If%20not%2C%20which%20version%3F%20Also%2C%20please%20share%20if%20you%20are%20implementing%20SDK%20or%20RTD%20drivers%2C%20and%20which%20version%20as%20well.%3C%2FP%3E%0A%3COL%3E%0A%3CLI%3E%3CSTRONG%3EWhy%20am%20I%20getting%20these%20register%20access%20errors%20while%20the%20CPU%20is%20running%3F%20Is%20there%20a%20setting%20to%20allow%20register%20reads%20during%20execution%20or%20must%20the%20CPU%20be%20halted%3F%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FSTRONG%3EThe%20CPU%20must%20be%20halted.%3CSTRONG%3E%3CBR%20%2F%3E%3C%2FSTRONG%3E%3C%2FLI%3E%0A%3CLI%3E%3CSTRONG%3EWhat%20could%20be%20the%20root%20cause%20for%20memory%20access%20at%200xDEADBEEE%3F%20Is%20this%20a%20common%20default%20value%20used%20for%20uninitialized%20pointers%20in%20NXP%20drivers%20or%20MCAL%3F%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FSTRONG%3EThe%200xDEADBEEE%20value%20mainly%20indicates%26nbsp%3Ban%20error.%20It's%20not%20a%20standard%20memory%20location%20but%20rather%20a%20value%20used%20to%20indicate%20that%20a%20memory%20section%20is%20uninitialized%2Fhas%20an%20error.%20I%20believe%20that%20in%20your%20case%3B%20it%20simply%20states%20that%20it%20cannot%20connect%20to%20the%20MCU%26nbsp%3B%3CSTRONG%3E%3CBR%20%2F%3E%3C%2FSTRONG%3E%3C%2FLI%3E%0A%3CLI%3E%3CSTRONG%3E%3CSTRONG%3EAny%20recommended%20way%20to%20handle%20these%20debugger%20limitations%20when%20developing%20low-level%20MCAL%20drivers%3F%3CBR%20%2F%3E%3C%2FSTRONG%3E%3C%2FSTRONG%3E%3CSTRONG%3E%3CSTRONG%3E%3CBR%20%2F%3E%3C%2FSTRONG%3E%3C%2FSTRONG%3EThe%20first%20and%20more%20obvious%20thing%20to%20say%20will%20be%20to%20double%20check%20that%20the%20connection%20is%20correct.%20If%20you%20were%20able%20to%20connect%20before%20but%20not%20now%2C%20then%20there%20are%20a%20couple%20of%20things%20that%20could%20be%20preventing%20from%20that%3A%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CUL%3E%0A%3CLI%3EDevice%20was%20using%20security%20features%20when%20performing%20mass%20erase.%3C%2FLI%3E%0A%3CLI%3EDevice%20is%20secured.%3C%2FLI%3E%0A%3CLI%3EFlash%20Configuration%20Field%20was%20compromised.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EPlease%20check%20the%20following%20application%20note%20where%20this%20issues%20are%20detailed%20described%3A%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20style%3D%22font-family%3A%20inherit%3B%20background-color%3A%20%23ffffff%3B%22%20href%3D%22https%3A%2F%2Fwww.nxp.com%2Fdocs%2Fen%2Fapplication-note%2FAN12130.pdf%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3EAN12130%3A%20Production%20Flash%20Programming%20Best%20Practices%20for%20S32K1xx%20MCUs%20%E2%80%93%20Application%20Note%3C%2FA%3E%3CBR%20%2F%3E%3CSTRONG%3E%3CBR%20%2F%3E%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EBest%20regards%2C%3CBR%20%2F%3EJuli%C3%A1n%3C%2FP%3E%0A%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E