FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

TWR-K65F180M no trace synchronization on 4-bit port

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

TWR-K65F180M no trace synchronization on 4-bit port

‎01-12-2017 03:41 PM
1,695 Views
adamdrewery
Contributor I

We are hoping to gain some clarity on using the 4-bit trace port of the TWR-K65F180M. I'm going to include everything we've tried here as it may help someone else as well.

Initially, we were having issues even getting JTAG to work. We followed the guidelines to remove the shunt on J32, but this did not allow us to utilize JTAG. We updated the bootloader firmware per this forum post:

JTAG in TWR-K65F180M not functional on rev A0 

Note: The forum response from Natish Harish contains the binary file you will want to use. I missed it the first few times.

After that, we were still unable to use JTAG. We then added 0 Ohm resistors for R54 - R58 (for the trace functionality) and R68, R69. This got us going with JTAG debugging. However, we are still having issues using the 4-bit trace mode.

We followed all of the configuration guidelines here:

ULINKpro User's Guide: Enable 4-Pin Trace (ETM) 

As the above link was for the K70, we modified it to point to the addresses of the corresponding registers on the K65. Our resultant initialization file is:

/*-------------------------------------------------------------------
** Define the function to enable the trace port
**-----------------------------------------------------------------*/
FUNC void SetupTrace(void) {

  _wDWORD(0x40048038,(_RDWORD(0x40048038) | 0x00002000));      // SIM_SCGC5  : Enable PORT E clock
  _wDWORD(0x40048004,(_RDWORD(0x40048004) | 0x00001000));      // SIM_SOPT2  : Trace Clock Source is set as "Core/system clock"
  _wDWORD(0x40048068,(_RDWORD(0x40048068) & 0xFFFFFFF0));      // SIM_CLKDIV4: Set TRACEDIV = b000 & TRACEFRAC = b0
                                                               // Note: Do not change the value of SIM_CLKDIV4[0..3] in your application!
  _wDWORD(0x4004D000, 0x00000740);  // PTE0: TraceClock, High drive strength
  _wDWORD(0x4004D004, 0x00000740);  // PTE1: TRACED3   , High drive strength
  _wDWORD(0x4004D008, 0x00000740);  // PTE2: TRACED2   , High drive strength
  _wDWORD(0x4004D00C, 0x00000740);  // PTE3: TRACED1   , High drive strength
  _wDWORD(0x4004D010, 0x00000740);  // PTE4: TRACED0   , High drive strength
}

/*-------------------------------------------------------------------
** Invoke the function at debugger startup
**-----------------------------------------------------------------*/
SetupTrace();

/*-------------------------------------------------------------------
** Execute upon software RESET
**-----------------------------------------------------------------*/
FUNC void OnResetExec(void)  {
  SetupTrace();
}

We have gotten some of the trace functionality to work but not with the 4-bit trace mode. We have tried changing our debugger clock speeds, and we have tried with matched/mis-matched core clock settings.

We have had success when using the ETB and slowing the debug clock down, but we do not see anything in the Event Viewer window. When we step through the code we can use ETB we are able to log several thousand (highest I saw was 7500 events), but if we just let it run we stop logging ETM after around 10 seconds. Using SWO - Manchester we can only see ITM data, and we see the events in the Event Viewer window. Similar to running the ETM port, we have to step through in order to log more than several thousand events.

We did have a few questions:

The Core Clock field needs to match the frequency of the actual clock on the MCU. Does it also need to match the Xtal field in the Target settings tab? The description makes it sound like the Xtal field should match the frequency of the external oscillator.

Do we need to install a 0 Ohm on R53?

In our initialization file, do we need to change the pin mulitplexing? The example did not do this, but it would seem to me that we ought to be assigning the multiplex assignment.

Are there any limitations for the 4-bit trace port that we are overlooking?

Any help would be greatly appreciated.

Thanks,

Adam

Labels (1)
Labels
0 Kudos
Reply
6 Replies

‎01-16-2017 03:07 PM
1,218 Views
adamdrewery
Contributor I
Some progress has been made and we can successfully record a trace.  I'll first outline the steps we took to get things working with the 'Sync Trace Port with 4-bit Data' settings.

Overview:
We are using Keil uVision 5.22 for development (latest version at the time of this post).

Here is a copy of the updated traceport.ini file we are using:

/*-------------------------------------------------------------------
** Define the function to enable the trace port
**-----------------------------------------------------------------*/
FUNC void SetupTrace(void) {

  _wDWORD(0x40048038,(_RDWORD(0x40048038) | 0x00002000));      // SIM_SCGC5  : Enable PORT E clock
  _wDWORD(0x40048004,(_RDWORD(0x40048004) | 0x00001000));      // SIM_SOPT2  : Trace Clock Source is set as "Core/system clock"
  _wDWORD(0x40048068,(_RDWORD(0x40048068) & 0xFFFFFFF0));      // SIM_CLKDIV4: Set TRACEDIV = b000 & TRACEFRAC = b0
                                                               // Note: Do not change the value of SIM_CLKDIV4[0..3] in your application!
  _wDWORD(0x4004D000, 0x00000540);  // PTE0 (ALT5): TraceClock, High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
  _wDWORD(0x4004D004, 0x00000540);  // PTE1 (ALT5): TRACED3   , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
  _wDWORD(0x4004D008, 0x00000540);  // PTE2 (ALT5): TRACED2   , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
  _wDWORD(0x4004D00C, 0x00000540);  // PTE3 (ALT5): TRACED1   , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
  _wDWORD(0x4004D010, 0x00000540);  // PTE4 (ALT5): TRACED0   , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
}

/*-------------------------------------------------------------------
** Invoke the function at debugger startup
**-----------------------------------------------------------------*/
SetupTrace();

/*-------------------------------------------------------------------
** Execute upon software RESET
**-----------------------------------------------------------------*/
FUNC void OnResetExec(void)  {
  SetupTrace();
}

1. Hardware Modifications:
  1. Remove J31 shunt
  2. Placed 0 Ohm for R54, R55, R56, R57, R58, R68, and R69
2. Load up the 'CMSIS-RTOS Blinky (TWR-K65F180M)' example project.
3. Changed "Options for target..." -> "Target" -> "Xtal (MHz)" .... to "16.0"
4. Changed "Options for target..." -> "C/C++" -> "Define:" .... to "SETUP_CLOCK=0"
5. Changed "Options for target..." -> "Debug" -> "Initialization File" .... uses the ini file above.
6. Changed "Options for target..." -> "Debug" -> "Run to main()" .... DISABLED
7. Changed "Options for target..." -> "Debug" -> "Settings" -> "Trace" ....
     - Core clock: 20.971520 MHz
     - Trace port: Sync Trace Port with 4-bit Data
     - All time offsets left at 0ns.
     - Set 'Trace Enable'
     - Set 'ETM Trace Enable'
     - Set 'EXCTRC: Exception Tracing'
     - ITM Stimulus Ports Enable: 0xFFFFFFFF
     - ITM Stimulus Ports Privilege: 0x00000008

Trace Capture:

Once all this is done, you *MUST* do the following to capture a trace:

- Unplug and replug the ULINKPro USB cable.

- Start a debug session with no breakpoints set.

With these steps we are able to reliably have a trace session and ETM/ITM data is populated on the 'Trace Data' window while debugging.

We also have events shown in the 'System and Thread Viewer' and 'Event Viewer' tabs during debug.

BUT, the moment you halt debugging (with a breakpoint, or manually) the status bar will show "Trace: Communication Error" in the status bar and no more data will appear in the 'Trace Data' and 'Event Viewer' windows.

However, the data continues to refresh on the 'System and Thread Viewer' window; only tracing data seems to be gone.

At this point you must unplug/replug ULINKPro USB cable and start another debug session (complete with the 30-second pause that the ULINKPro seems to require every time you unplug it and use it for the first time) to get trace data back.

Other things we have tried/noticed:

- We have adjusted the core clock from 4MHz to 180MHz and in between to see how tracing is affected. Changing the clock always causes the trace to fail at the point where the clock speed is adjusted.
- We have verified the TRACE_CLKOUT frequency is changing while we are adjusting the core clock.  It does speed up/down as expected. When measured, its frequency is always half of the core clock frequency.

- The trace clock appears to continue run while the processor is stopped.

At this point it appears to be a problem with Keil and/or the ULINKPro driver.  Unless we are missing something else in the initialization of the traceport.ini file we're at a loss.  It doesn't seem to be a very useful trace if it stops when a break point is hit.

Also, we're not sure how to automatically tell the trace/debugger that we are going to change the clock speed.  How can we run trace at anything beyond the default 20.971520 MHz that the processor comes up at?

0 Kudos
Reply

‎01-18-2017 01:53 PM
1,218 Views
tsi-chung_liew
NXP Employee
NXP Employee

Adam,

The Trace clock depends on two clock sources - MCGOUTCLK and Core/system in SIM_SOPT2[TRACECLKSEL]. The trace clock divider setup in SIM_CLKDIV4[TRACEFRAC,TRACEDIV]. The TRACE_CLKOUT pin will be at maximum half of the selected clock source. You can't achieve 120 (NORMAL)/180 (HSRUN) MHz on TRACE_CLKOUT, the best can be no more than 60 (120MHz Core) or 90 (180MHz Core) MHz with proper TRACEFRAC and TRACEDIV setup.

I will see if I can duplicate the symptom you described about changing clock speed while debugging.

Regards,

TsiChung

0 Kudos
Reply

‎01-19-2017 08:29 AM
1,219 Views
adamdrewery
Contributor I

TsiChung,

Thank you for confirming the divide by two, and thank you for taking a look at this. Are you sure that we should be able to debug with a 180 MHz core clock? Page 121 (Table 6-1) of the K65P reference manual shows that the TRACEKLIN signal is limited to 120 MHz. Would we simply need to set a divider via SIM_CLKDIV4[TRACEFRAC, TRACEDIV]? Everything I've seen thus far suggests we don't want to do that.

We have also been in contact with ARM. We are starting to think there may be an issue with the ULINK Pro firmware. We are able to get trace functionality working until we hit a breakpoint or halt debugging. However, once we start debugging again the trace clock does not re-synchronize. I will keep updating as we find out more.

Thanks,

Adam

0 Kudos
Reply

‎01-24-2017 04:13 PM
1,219 Views
tsi-chung_liew
NXP Employee
NXP Employee

Adam,

I agreed that the trace clock should be 120MHz.

Regards,

TsiChung

Reply

‎01-15-2017 11:18 AM
1,218 Views
adamdrewery
Contributor I

We have modified our initialization file to correct the pin multiplex assignments. We were setting the alternates for PTE0 - 4 to ALT3, but they needed to be set to ALT5.

/*-------------------------------------------------------------------
** Define the function to enable the trace port
**-----------------------------------------------------------------*/
FUNC void SetupTrace(void) {
_wDWORD(0x40048038,(_RDWORD(0x40048038) | 0x00002000)); // SIM_SCGC5 : Enable PORT E clock
_wDWORD(0x40048004,(_RDWORD(0x40048004) | 0x00001000)); // SIM_SOPT2 : Trace Clock Source is set as "Core/system clock"
_wDWORD(0x40048068,(_RDWORD(0x40048068) & 0xFFFFFFF0)); // SIM_CLKDIV4: Set TRACEDIV = b000 & TRACEFRAC = b0
// Note: Do not change the value of SIM_CLKDIV4[0..3] in your application!
_wDWORD(0x4004D000, 0x00000540); // PTE0 (ALT5): TraceClock, High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
_wDWORD(0x4004D004, 0x00000540); // PTE1 (ALT5): TRACED3 , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
_wDWORD(0x4004D008, 0x00000540); // PTE2 (ALT5): TRACED2 , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
_wDWORD(0x4004D00C, 0x00000540); // PTE3 (ALT5): TRACED1 , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
_wDWORD(0x4004D010, 0x00000540); // PTE4 (ALT5): TRACED0 , High drive strength, Passive Filter Disabled, Slew Rate Fast, No pull
}
/*-------------------------------------------------------------------
** Invoke the function at debugger startup
**-----------------------------------------------------------------*/
SetupTrace();
/*-------------------------------------------------------------------
** Execute upon software RESET
**-----------------------------------------------------------------*/
FUNC void OnResetExec(void) {
SetupTrace();
}

We have also come across this link that looks like it may help.

ULINKpro User's Guide: Compensate Signal Delays 

0 Kudos
Reply

‎01-13-2017 01:25 AM
1,218 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

I am also interested in the subject, I have asked someone  for help already.

BR

XiangJun Rong

0 Kudos
Reply