Tag Archives: debug

SystemView PRO – Analyze your Firmware Behavior Like a PRO

Segger Microcontroller is known for J-Links device about debugging and programming lots of architectures: ARM, Microchip PIC32 and Renesas RX. Segger provides a lot of other software and hardware tools for debugging and programming purposes; SystemView is one of these tools.

SystemView gives a complete insight of what is going inside the MCU graphically and in real time. All recorded data is fetched using J-link adapter with no extra hardware or extra pins. SystemView app requires small software module (< 2 KB) to be included in the device.

SystemView app GUI

The SystemView module collects the data and passes it to Real Time Transfer (RTT). The RTT module stores the data in the device buffer, which enables continuous recording. SystemView has the ability of analyzing which interrupts, tasks and software timers executed, how many times and when.

Segger announced a new PRO version for SystemView; with unlimited recording and creating custom filters for event, SystemView PRO extends the normal version. However, the free version “SystemView” is limited up to 1 million event recording and analyzing. Last but not least, buying the PRO version costs about 1,200 USD. Another option, is that you can purchase a J-Link and it will be shipped with a SEGGER SystemView PRO license (seems more economical option) .

Source: electropages

ULINKplus, A Debug Adapter With Power Measurment

While building an ultra-low power application, sensitive hardware and software validation is required to reach system and long battery life. Testing will need an interaction with the tested parts, like simulating input pins of the target application.

These difficulties could be solved with ARM’s new debug adapter “ULINKplus“. It connects the target system with the PC through USB port using a 10-pin Cortex Debug connector. Its power measurement technology allows developers to program, debug, and analyze their applications and their power consumption.

Main features of ULINKplus are:

  • Integrated power measurement synchronized to event tracing which makes it easy to optimize the overall energy envelope of a system.
  • Isolated JTAG/serial-wire connection to the target hardware is essential for testing applications such as motor control, power converters, or systems with sensitive analog processing.
  • Additional test I/O pins are accessible from the debugger and debug scripts to interact with the target and control automated test stands.

ULINKplus, together with MDK, provides extended on-the-fly debug capabilities for Cortex-M devices. You can control the processor, set breakpoints, and read/write memory contents, all while the processor is running at full speed. High-Speed data trace enables you to analyze detailed program behavior.

In addition to downloading programs to your target hardware, you will be able to examine memory and registers, single-step through programs and insert multiple breakpoints, to run programs in real-time, program Flash memory, and to connect to running targets (hot-plugging).

Live data from power measurement

ULINKplus offers a high speed connections that reach 50 Mbit/s for data and event trace for Cortex-M, 20 MHz JTAG clock speed, and 3 MBytes/s high-speed memory read/write.

ULINKplus technical specifications:

  • Compact case 62 x 44 x 11 mm (dust-protected)
  • JTAG/SWD: 20 MHz JTAG clock, 50 MHz serial-wire trace, 10-pin Cortex debug connector, 1 kV isolation
  • Memory access 3 MB/sec, serial-wire trace up to 50 Mbit/sec
  • Power measurement: 2 x 16-bit A/D, 400 KSamples/sec, 3-pin connector, 1 kV isolation
  • Test I/O: 9 digital in/out, 4 analog in, 1 analog out, 3.3 V switchable output voltage (11-pin connector)
  • Debug connection: USB2.0 (to host PC), CMSIS-DAP protocol

According to ARM, ULINKplus will be available from this month.

ARM CoreSight SoC-600, The Future of Debug

Debugging is an important part of the design process that is necessary to identify and fix errors. Over the decades, debug tools had evolved providing easier and simpler solutions. Today, ARM introduces CoreSight SoC-600 as the next-generation debug and trace tool that speeds up finding the root of the problem, with less iterations and lower risks.

Addressing the requirements of the increasingly connected world characterized by faster product-development cycles, this new technology offers debug and trace over functional interfaces such as USB, PCIe or wireless, reducing the need for hardware debug probes while increasing data throughput.

Key benefits include:

  • Debug access available and accessible throughout the product lifecycle, from production and manufacture, to remote access in the field
  • Remote debug access (e.g. via Ethernet or wirelessly)
  • Increased data bandwidth for improved system visibility
  • Multiple debug agents can simultaneously access debug memory space (e.g. for concurrent external and self-hosted access)
  • Interface peripherals (such as USB and PCIe) share a common access to APs, together with any existing JTAG DP or resident software
  • Self-hosted, cross CPU debug access

CoreSight SoC-600 comes with a new Debug Access Port (DAP) architecture. It introduces standard APB connectivity between Debug Port (DP) and Access Port (AP), making it possible to have multiple DPs connected to multiple APs.

CoreSight SoC-600 also includes an enhanced Embedded Trace Router (ETR) functionality. In additional to removing the need for a separate Trace Memory Controller (TMC) license, enhancements to the Embedded Trace Router (ETR) configuration make it possible to supply a trace interface with four times the amount of bandwidth previously possible.

There are two approaches to host the link protocol when building a CoreSight SoC-600-based system:

  1. Protocol on dedicated CPU: this approach comes at a cost of additional dedicated resources, however, it is the least intrusive approach and provides bare metal debug capabilities.
  2. Protocol on main CPU: this approach does not require additional hardware, yet it is invasive and relies on CPU not being halted.

For further information and details about SoC-600 you can visit the official page, and the official article on ARM website.

Issues with printf function

The C library function printf() is one of the common used functions in embedded systems world to debug the code in real time over a serial connection. Using the printf() over serial is under debate and may not be optimal for embedded systems and that’s what Jacob Beningo over EDN tries to demonstrate.

The first problem with using printf() is the need to bring a standard C library into the software which consumes a lot from RAM and ROM/Flash which are limited in size. The second problem is during the execution time of printf() where system becomes blocked until all characters have been transmitted.

 

Timing Diagram For Printing “Hello World!” Using printf() Through A UART At 9600 Baud - Image courtesy of EDN
Timing Diagram For Printing “Hello World!” Using printf() Through A UART At 9600 Baud – Image courtesy of EDN

Jacob addressed some solutions and alternatives. One of them was developing a non blocking version of printf() that uses an interrupt service routine to handle transmission of buffer content.

Performance Of The Non-blocking Version - Images courtesy of EDN
Performance Of The Non-blocking Version – Images courtesy of EDN

Another solution is to use SWD (Single Wire Debugger) interface, a 2-pin debug port for ARM MCUs, which minimizes software overhead where an internal buffer gets filled and the debug hardware automatically handles transmission to the debug probe. You can read more about SWD in ARM website.

Via: EDN