<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Debugging Issue with S32K144 MCU Using SEGGER J-Link and S32DS IDE in S32K</title>
    <link>https://community.nxp.com/t5/S32K/Debugging-Issue-with-S32K144-MCU-Using-SEGGER-J-Link-and-S32DS/m-p/2142977#M51442</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/253114"&gt;@Gowtham_768&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;Sorry to reply with more answers, but please help me confirm this information:&lt;/P&gt;
&lt;P&gt;Is this the first time you are trying to connect to the board, or were you able to debug and connect before?&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;&lt;STRONG&gt;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?&lt;BR /&gt;&lt;BR /&gt;&lt;/STRONG&gt;The CPU must be halted.&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;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?&lt;BR /&gt;&lt;BR /&gt;&lt;/STRONG&gt;The 0xDEADBEEE value mainly indicates&amp;nbsp;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&amp;nbsp;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;&lt;STRONG&gt;Any recommended way to handle these debugger limitations when developing low-level MCAL drivers?&lt;BR /&gt;&lt;/STRONG&gt;&lt;/STRONG&gt;&lt;STRONG&gt;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/STRONG&gt;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:&lt;/LI&gt;
&lt;/OL&gt;
&lt;UL&gt;
&lt;LI&gt;Device was using security features when performing mass erase.&lt;/LI&gt;
&lt;LI&gt;Device is secured.&lt;/LI&gt;
&lt;LI&gt;Flash Configuration Field was compromised.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Please check the following application note where this issues are detailed described:&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;A style="font-family: inherit; background-color: #ffffff;" href="https://www.nxp.com/docs/en/application-note/AN12130.pdf" target="_blank" rel="nofollow noopener noreferrer"&gt;AN12130: Production Flash Programming Best Practices for S32K1xx MCUs – Application Note&lt;/A&gt;&lt;BR /&gt;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;Best regards,&lt;BR /&gt;Julián&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Tue, 29 Jul 2025 21:46:12 GMT</pubDate>
    <dc:creator>Julián_AragónM</dc:creator>
    <dc:date>2025-07-29T21:46:12Z</dc:date>
    <item>
      <title>Debugging Issue with S32K144 MCU Using SEGGER J-Link and S32DS IDE</title>
      <link>https://community.nxp.com/t5/S32K/Debugging-Issue-with-S32K144-MCU-Using-SEGGER-J-Link-and-S32DS/m-p/2141153#M51361</link>
      <description>&lt;P&gt;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):&lt;/P&gt;&lt;P&gt;Hi everyone,&lt;/P&gt;&lt;P&gt;I'm working on &lt;STRONG&gt;S32K144&lt;/STRONG&gt; and currently developing &lt;STRONG&gt;custom MCAL drivers&lt;/STRONG&gt;. I'm using the &lt;STRONG&gt;SEGGER J-Link debugger&lt;/STRONG&gt; along with &lt;STRONG&gt;S32 Design Studio (S32DS)&lt;/STRONG&gt; for development.&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;PRE&gt;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  &lt;/PRE&gt;&lt;P&gt;&lt;STRONG&gt;Observations:&lt;/STRONG&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;These errors appear as soon as the target starts running.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;It seems like the debugger is unable to access system or floating-point registers while the CPU is in execution mode.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;The memory warning is pointing to an invalid address: 0xDEADBEEE.&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;STRONG&gt;Current Setup:&lt;/STRONG&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;MCU: NXP S32K144 (ARM Cortex-M4F)&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;IDE: S32 Design Studio&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Debugger: SEGGER J-Link (SWD mode, 1 MHz)&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Application: Bare-metal, developing and testing custom MCAL drivers&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Debug Mode: Connected via GDB server and flashing/debugging through S32DS&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;STRONG&gt;Questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;Why am I getting these register access errors while the CPU is running?&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;Is there a setting to allow register reads during execution or must the CPU be halted?&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;What could be the root cause for memory access at 0xDEADBEEE?&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;Is this a common default value used for uninitialized pointers in NXP drivers or MCAL?&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;Any recommended way to handle these debugger limitations when developing low-level MCAL drivers?&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Thank you&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 26 Jul 2025 03:19:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/Debugging-Issue-with-S32K144-MCU-Using-SEGGER-J-Link-and-S32DS/m-p/2141153#M51361</guid>
      <dc:creator>Gowtham_768</dc:creator>
      <dc:date>2025-07-26T03:19:58Z</dc:date>
    </item>
    <item>
      <title>Re: Debugging Issue with S32K144 MCU Using SEGGER J-Link and S32DS IDE</title>
      <link>https://community.nxp.com/t5/S32K/Debugging-Issue-with-S32K144-MCU-Using-SEGGER-J-Link-and-S32DS/m-p/2142977#M51442</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/253114"&gt;@Gowtham_768&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;Sorry to reply with more answers, but please help me confirm this information:&lt;/P&gt;
&lt;P&gt;Is this the first time you are trying to connect to the board, or were you able to debug and connect before?&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;&lt;STRONG&gt;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?&lt;BR /&gt;&lt;BR /&gt;&lt;/STRONG&gt;The CPU must be halted.&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;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?&lt;BR /&gt;&lt;BR /&gt;&lt;/STRONG&gt;The 0xDEADBEEE value mainly indicates&amp;nbsp;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&amp;nbsp;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;&lt;STRONG&gt;Any recommended way to handle these debugger limitations when developing low-level MCAL drivers?&lt;BR /&gt;&lt;/STRONG&gt;&lt;/STRONG&gt;&lt;STRONG&gt;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/STRONG&gt;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:&lt;/LI&gt;
&lt;/OL&gt;
&lt;UL&gt;
&lt;LI&gt;Device was using security features when performing mass erase.&lt;/LI&gt;
&lt;LI&gt;Device is secured.&lt;/LI&gt;
&lt;LI&gt;Flash Configuration Field was compromised.&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Please check the following application note where this issues are detailed described:&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;A style="font-family: inherit; background-color: #ffffff;" href="https://www.nxp.com/docs/en/application-note/AN12130.pdf" target="_blank" rel="nofollow noopener noreferrer"&gt;AN12130: Production Flash Programming Best Practices for S32K1xx MCUs – Application Note&lt;/A&gt;&lt;BR /&gt;&lt;STRONG&gt;&lt;BR /&gt;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;Best regards,&lt;BR /&gt;Julián&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 29 Jul 2025 21:46:12 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/Debugging-Issue-with-S32K144-MCU-Using-SEGGER-J-Link-and-S32DS/m-p/2142977#M51442</guid>
      <dc:creator>Julián_AragónM</dc:creator>
      <dc:date>2025-07-29T21:46:12Z</dc:date>
    </item>
  </channel>
</rss>

