NXP MWCT2xxxS
The MWCT2xxxS family from NXP are Cortex-M7 based MCUs for Wireless charging Transmitter ICs.
Internal Flash
Supported Regions
MWCT2014S
| Flash Bank | Base address | Size | J-Link Support |
|---|---|---|---|
| Code flash | 0x00400000 | 512 KB | |
| Data flash | 0x10000000 | 64 KB | |
| UTEST (OTP) | 0x1B000000 | 8 KB |
MWCT2015S
| Flash Bank | Base address | Size | J-Link Support |
|---|---|---|---|
| Code flash 0 | 0x00400000 | 512 KB | |
| Code flash 1 | 0x00480000 | 512 KB | |
| Data flash | 0x10000000 | 128 KB | |
| UTEST (OTP) | 0x1B000000 | 8 KB |
MWCT2016S & MWCT2D16S
| Flash Bank | Base address | Size | J-Link Support |
|---|---|---|---|
| Code flash 0 | 0x00400000 | 1 MB | |
| Code flash 1 | 0x00500000 | 1 MB | |
| Data flash | 0x10000000 | 128 KB | |
| UTEST (OTP) | 0x1B000000 | 8 KB |
MWCT2D17S
| Flash Bank | Base address | Size | J-Link Support |
|---|---|---|---|
| Code flash 0 | 0x00400000 | 1 MB | |
| Code flash 1 | 0x00500000 | 1 MB | |
| Code flash 2 | 0x00600000 | 1 MB | |
| Code flash 3 | 0x00700000 | 1 MB | |
| Data flash | 0x10000000 | 128 KB | |
| UTEST (OTP) | 0x1B000000 | 8 KB |
ECC RAM
The ITCM and DTCM must be properly initialized with correct ECC before any read operation to avoid any code runaway or software malfucntion or core lockup. ITCM must be initialized with 64-bit writes whereas DTCM can be initialized with 32-bit or 64-bit writes. The following memory ranges are initialized by the J-Link on connect by default. Other ranges needs to be initialized by the application / boot ROM.
| Memory | Address | Size |
|---|---|---|
| ITCM0 | 0x00000000 | 32 KB |
| DTCM0 | 0x20000000 | 32 KB |
| SRAM0 | 0x20400000 | 16 KB |
Skipping DTCM0 Initialization
This script disables DTCM0 memory initialization during the connection sequence. MWCT2xxxS_NoDTCM0Init.JLinkScript
Skipping complete RAM Initialization
This script disables the complete RAM initialization during the connection sequence. MWCT2xxxS_NoRAMInit.JLinkScript
Initialization of the work RAM is skipped in case the attach feature of J-Link is used (exec ForceAttachTarget=1)
Watchdog Handling
- The device has up to 2 watchdogs (SWT0, SWT1) depending on the specific MCU and number of Cortex-M7 cores.
- If the watchdog of the core connected to is enabled, it is turned off during flash programming and turned back on afterwards.
HSE activated
In case of HSE firmware is installed, there are two configurations:
- FULL_MEM (code flash is considered as one region)
- AB_SWAP (code flash is split into two regions)
In case of FULL_MEM, the HSE is located at the end of the last code flash memory. Access to this region is prohibited.
In case of AP_SWAP is used, the code flash will be split into two regions. In this case, the HSE is available twice (once per region) and located at the end of both regions.
Multi-Core Support
Before proceeding with this article, please check out the generic article regarding Multi-Core Debugging.
The MWCT2xxxS family comes with a variety of multi-core options. Usually co-processors are disabled after reset / by default thus needs to be enabled by the J-Link on connect. Some of them are running in permanent lockstep mode, some are operating in optional lockstep mode and others are pure single core co-processors. In below, the debug related multi-core behavior of the J-Link is described for each core:
Main core (Cortex-M7_0)
Init/Setup
- Initializes the ECC RAM, see ECC RAM
- Enables debugging
- If a connection is not otherwise possible, a connect under reset is performed. See Reset
Reset
- Device specific reset is performed, see Reset
Attach
- By default, the ECC RAM is initialized thus attach is not possible. In order to attach to the target, the exec ForceAttachTarget=1 command string needs to be used.
- Attach is not possible if a connect under reset would have to be performed. See Reset
Secondary core (Cortex-M7_1)
Init/Setup
- If the main core session has not been started / debugging is not enabled yet, the secondary core executes the enable debug sequence.
- If the secondary core is not enabled yet, it will be enabled / released from reset
- Initializes the ECC RAM, see ECC RAM
Reset
- No reset is performed.
Attach
- Attach is supported / desired. Note that the ECC RAM will be initialized anyhow. In order to skip the ECC RAM init, the exec ForceAttachTarget=1 command string needs to be used.
Reset
The J-Link performs a device specific reset sequence. The reset is executed for the main core, only. Reset of the main core, resets / disables the secondary core if used in parallel.
The reset pin needs to be connected in order to guarantee a proper reset.
Debug Authentication
The MWCT2xxxS family supports different security mechanisms. The following table provides an overview of which types are supported and which are not:
| Silicon type | Info | J-Link Support |
|---|---|---|
| E5 | Configured for Secure boot assist flash (SBAF) | |
| E6 | Configured for secure application debug with password authentication. | |
| E7 | Configured for secure application debug with challenge/response authentication. |
Depending on the authentication level, debug access can be granted if the correct key is passed. How this is possible is described below.
Specifying the authentication code using J-Link Command String
This is the recommended method as the specified authentication key will be used for the whole session. This way, the key must not specified multiple times (e.g. if a reset is performed). The J-Link Command String needs to be passed to the J-Link DLL before establishing the target connection. The J-Link Command String SetCPUConnectIDCode <AuthKey> has to be used (see example below).
Example authentication key:
- AuthenticationKey0: 0x01234567
- AuthenticationKey1: 0x89ABCDEF
- AuthenticationKey2: 0x00224466
- AuthenticationKey3: 0x88AABBCC
exec SetCPUConnectIDCODE 67452301EFCDAB8966442200CCBBAA88
Specifying the authentication code using the ID Code dialog
If the authentication key has not been specified using the Command String although it is required to enable debug access, the following message box will pop up which allows specifying the authentication key.
Limitations
Security / Authentication
There are three different types available in regard to the security. The following table provides an overview of which types are supported and which are not:
| Silicon type | Info | J-Link Support |
|---|---|---|
| E5 | Configured for Secure boot assist flash (SBAF) | |
| E6 | Configured for secure application debug with password authentication. | |
| E7 | Configured for secure application debug with challenge/response authentication. |
SystemView
With J-Link software V7.84e ECC RAM handling was added. So it is no longer possible to run a debug session in parallel with SystemView, as the connect from SystemView will reinitialize the ECC RAM init and overwrite the RTT buffers. To avoid this the following .JLinkScript file must be added to SystemView.
MWCT2xxxS_SystemView.JLinkScript
How to add a .JLinkScript to SystemView is explained here: J-Link_script_files#SystemView
MPU faults during connection
On some MWCT2xxxS projects, the MPU configuration restricts write access to specific memory regions. When the J-Link attempts to initialize the ITCM0 or DTCM0 RAM area during the connection sequence, these write protections can trigger an MPU fault, causing the connection to fail. To prevent this, you can add one of the following J-Link script files to your project.
Alternatively, you can modify your project’s debug configuration to avoid restricting access to the ITCM0 and DTCM0 regions.
J-Scope
Starting with J-Link software V7.84e, ECC RAM handling was introduced. Upon connect, J-Link reinitializes the RAM, which may overwrite existing RTT buffers. To prevent this behavior, one of the following .JLinkScript files can be used:
