When a new application project is created using the New Project Wizard, it is possible to select the debugger to be used. This results in the associated debugger configurations being created within the new project. But what if support for multiple debuggers is required or it is desired to switch to a different debugger? There are easy ways to resolve this. One is as simple as creating a new debug configuration. Another method is by creating new application project, selecting the new debugger to be supported. Then either repurposing the associated debug configuration or duplicating then modifying the debug configuration to support instead the previously existing project. This minimizes the effort by benefiting from the automation of the New Project Wizard.   Detailed below are the steps to add a new debug configuration.  Create A New S32 Debugger Configuration Load the existing project. For this demonstration, the SDK project ‘hello_world_s32v234’ will be used. Select the project so it appears highlighted in blue. Notice that the other project, ‘New_App_Project’, is bold text. This is because the main.c file open in the editor window to the right is the currently selected source file and is from this project. This has no effect on the process detailed in this document. Check that the existing project has been build and the executable is present. If the executable is not present, then an error will be displayed within the Debug Configurations menu and the executable file will need to be selected in a later additional step after it has been created. Open the Debug Configurations menu. Run -> Debug Configurations   Now select the Debugger Group for which you wish to create the new configuration. In this case, we will select ‘S32 Debugger’. Next, click ‘New Launch Configuration’ Now a new Debug Configuration has been created for your project and for the S32 Debugger. Most of the fields are already completed for you. Select the Debugger tab to see the source of the error message. The error message indicates ‘Specify Device and Core’. So click on ‘Select device and core’. Now expand the lists until the Device and Core are visible. Select the correct core for your project. In the demonstration example, the correct Device and Core are ‘S32V234’ and ‘M4’, respectively. Click OK, when done. If you have a debug probe connected, it may have been detected. If not, the Debug Probe Connection section will need to be completed. Now select the ‘Common’ tab to setup the storage location for this new Debug Configuration. Select ‘Shared file’ and then ‘Browse…’ Expand the lists until ‘Project_Settings/Debugger’ is open. Select ‘Debugger’, then click OK. Now the basic debug configuration settings are complete. It is now ready to be used and the Debug button could be clicked to start debug. Otherwise, you may have more customizations to make, such as for Attach Mode. Repurpose S32 Debugger Configuration From A New Project Create new project New -> S32DS Application Project New Project Wizard, processor and toolchain page Enter a project name Select the device and core to match the existing project If necessary, select the toolchain to match the existing project Click Next New Project Wizard, cores and parameters page Select the number of cores to match the existing project Select the debugger, S32 Debugger If necessary, select other parameters to match the existing project Click Finish   Open existing project which does not already have the S32 Debugger debug configurations (for this demonstration, we will use the hello_world_s32v234 example project from the S32 SDK) Copy debug configurations and modify settings to adapt to existing project Run -> Debug Configurations... Debug Configurations window Within the S32 Debugger grouping, select the debug configuration for the new project which corresponds to the build configuration and core of the existing project Change the name of the debug configuration. Change the portion of the name containing the project name to match the name of the existing project. Main tab Project field Click Browse... Select existing project C/C++ Application Click Search Project... Select the Elf file Common tab Save as field Click Browse... Select {existing_project_name}\Project_Settings\Debugger Debugger tab, Debug Probe Connection Setup connection parameters Click Apply Repeat as needed for all core/build config options The existing project now has the S32 Debugger configurations and is ready for debug with the S32 Debug Probe.

This release of S32K144W Bootloader was compiled and tested with the following development tools: S32DS Rappid Bootloader  Tested on the hardware: Development Board S32K14XCVD – 0064 Processor  PS32K144WAWLH 0P64A – CTZW2009B   Supported communication: UART1 (Speed:115200b/s): J16 on the S32K-MB Motherboard. CAN_A (Speed: 500Kb/s): J72 on the S32K-MB Motherboard.

The S32 Flash Tool is provided with support for a few QuadSPI flash memory devices which are typically the devices provided as part of the standard NXP EVB for each of the support NXP Automotive Processors. This will work for most users, but some may select a device for which support is not included with the tool. The FlashSDK was created to provide an easy method for adding support for additional QuadSPI flash memory devices to the S32 Flash Tool. First, a brief explanation of how the S32 Flash Tool works. The S32 Flash Tool programs external flash devices such as QuadSPI, SD, MMC, and eMMC. For each external flash device, there is a flash device-specific flash algorithm file. This flash algorithm file is downloaded by S32 Flash Tool to the target device SRAM, where it will be executed by the target device BootROM. The S32 Flash Tool then sends commands to the flash algorithm along with the image to be programmed to external flash. The flash algorithm will perform the programming of the image to the external flash device. The Flash SDK provides the capability to produce new flash algorithm files, which could then be uploaded to the target device by the S32 Flash Tool and then used to program images to the associated external flash device. The FlashSDK is provided in the form of a S32 Design Studio for S32 Platform v3.x project. This example project, as provided, will build and output a binary file similar to the MX25UM51245G.bin, MX25UW51245G.bin files included in the S32 Flash Tool. The project is designed to build for the Arm M7 core. It is located within the S32 Flash Tool installation directory and inside the folder 'FlashSDK_Ext'. For example, since the S32 Flash Tool is included within the S32 Design Studio 3.x, if the default installation settings were used, this could be found at the path: C:\NXP\S32DS.3.x\S32DS\tools\S32FlashTool\FlashSDK_Ext There is some limited documentation included with the FlashSDK, it can be found by navigating to the '...\FlashSDK_Ext\doc\html' directory and then open 'index.html' with your web browser. In this document, an example process for using the FlashSDK to produce a new binary file will be detailed. Prerequisites Install S32 Design Studio Locate or prepare an image file to be programmed to flash memory Setup hardware to Serial Boot mode Procedure Launch the S32 Design Studio Import the FlashSDK project, using copy to workspace option to preserve the original project. File -> Import Select 'Existing Projects from Workspace' Click 'Browse', locate and then select the 'FlashSDK_Ext' folder, check the box for 'Copy projects into the workspace' Open source files. The files in the project which should be modified for a new flash device are: ...\FlashSDK\Algo\Generic\qSPI_Algorithm.c and qSPI_chip_commands.h Locate the files within the Project Explorer and double click them to open them in the editor. Edit source files. The header file 'qSPI_chip_commands.h' contains many #defines for the flash memory chip which should be adjusted to your new device. Please refer to the reference manual provided by the flash device manufacturer for details on the correct values. As you can see, it is currently setup for the MX25UM51245G device from Macronix. Build the project. The project is setup for 2 build types for you, Debug and Release. The Release build type is more efficient and will run faster, and the Debug build type will allow you to run the debugger in attach mode to investigate issues with the changes you've made. Test new binary on the target and flash memory device. Follow the usual steps to use the S32 Flash Tool.

A typical debug session will begin by downloading code to Flash and then debugging from main() onwards. However, to explore an already running system a debug connection (attach) can be made to the target MCU without affecting the code execution (at least until the user chooses to halt the MCU!).   Note: Source level debug of a running target is only possible if the sources of the project to be attached exactly match the binary code running on the target.   Click the (Debug As) button on the toolbar, then click Debug Configurations from the drop-down menu. In the left pane of the Debug Configurations dialog box, expand the debugging interface specified in the project settings and click the required launch configuration. After you click the configuration in the left pane, the configuration settings appear in the right pane grouped in tabs. PEmicro Select the Startup tab, then set the ‘Attach to Running Target’ check box as below: When a debug connection is made, the target will continue running until it is paused.   SEGGER J-Link Select the Debugger tab, then set the ‘Connect to running target’ check box as below: Unfortunately, this feature currently not supported.

Watchpoints are Breakpoints for Data and are often referred to as Data Breakpoints. Watchpoints are a powerful aid to debugging and work by allowing the monitoring of global variables, peripheral accesses, stack depth etc. The number of watchpoints that can be set varies with the MCU family and implementation. Watchpoints are implemented using watchpoints units which are data comparators within the debug architecture of an MCU/CPU and sit close to the processor core. When configured they will monitor the processor’s address lines and other signals for the specific event of interest. This hardware is able to monitor data accesses performed by the CPU and force it to halt when a particular data event has occurred. The method for setting Watchpoints is rather more hidden within the IDE than some other debugging features. One of the easiest ways to set a Watchpoint is to use the Outline View. From this view you can locate global and static variables then simply select Toggle Watchpoints.     Once set, they will appear within the Breakpoints pane alongside any breakpoints that have been set.    Watchpoints can be configured to halt the CPU on a Read (or Load), Write (or Store), or both. Since watchpoints ‘watch’ accesses to memory, they are suitable for tracking accesses to global or static variables, and any data accesses to memory including those to memory mapped peripherals.  Note : To easily distinguish between Breakpoints and Watchpoints within the Breakpoint view, you can choose to group entries by Breakpoint type. From within the Breakpoints view, click the Eclipse Down Arrow Icon Menu, then you can select to Group By Breakpoint Types as shown below:   As you can see from the above graphic, the option to set a Watchpoint is also available directly from the Breakpoint view.   When set from here, you will be offered an unpopulated dialogue – simply entering an address will cause a watchpoint to be created, monitoring accesses to that location.     Another place to set Watchpoints within the IDE is from the context sensitive menu within a Memory view.   Unfortunately, the conditional watchpoints in S32 Design Studio for S32 Platform 3.3 may not work in some cases.