PI Zi Heng embedded: setting different reset types during IAR online debugging may lead to inconsistent debugging phenomena under i.mxrt (j-link / daplink)

Time:2020-11-8

Hello, everyone. I’m a ruffian. I’m a real technical ruffian. Heng is to share with you todaySetting different reset types in IAR online debugging may lead to inconsistent debugging phenomena under i.mxrt

There are a lot of IDE available for Cortex-M core MCU embedded software development. We will not mention the classic GCC. We will choose different MCU masters. If the MCU comes from a well-known manufacturer, the manufacturer will also launch special IDE (for example, MCU Xpresso ide of NXP semiconductor, truestudio and stm32uberide of STM32 semiconductor). In addition, there are several independent ides from specialized software companies, such as keil MDK and IAR EWARM. Because independent ides are not bundled with specific MCU manufacturers, and in order to maintain commercial competitiveness, they often perform better in performance and ease of use, so the market share remains high.

During his schooling, he mainly used keil MDK, and he has been using IAR EWARM since he started his work. When he just graduated, his version of IAR was v6.50. Seven years later, IAR has also developed to v8.50. The interface has become more beautiful and the function has become more powerful. Therefore, ruffian Henghui will continue to introduce the experience of IAR in details. What I want to talk about today is the influence of reset type setting in online debugging on i.mxrt debugging execution.

1、 IAR debugging mechanism

Before I talk about the details of reset type setting in IAR debugging, I’d like to give you a brief introduction to the debugging mechanism of IAR. The following figure shows a typical hardware connection for embedded development and debugging. First, you need to have a MCU main control board, and then you need to have a hardware simulator (such as j-link / daplink) to connect your PC and MCU board through the emulator Open your application project with IAR on C, and then you can debug and debug happily.

You should know that the Cortex-M debugging module is built in the MCU. With the help of hardware simulator, IAR can interact with the MCU debugging module through the debugging port to send and receive debugging data. But do you know who is in charge of debugging functions in the IAR? C-spy is a special debugging component built in IAR. When debugging, you can view assembly code, modify variable data, set breakpoints, step by step, check call stack and other functions in the background. The figure below is a sketch of the joint work of c-spy and all potential target systems. The blue box is applicable to the common scenario of joint use with j-link / daplink

C-spy supports a wide range of hardware emulators, which are implemented by designing corresponding c-spy drivers. Different simulators support different debugging features. For details, please refer to the following table for details: IAR systems / embedded workbench x.xx. X / arm / Doc / EWARM_ DebuggingGuide.ENU The “driver differences, i-jet, j-link / J-TRACE and st-link” table in the document.

2、 Two debugging categories (in flash / in RAM)

On i.mxrt, online debugging can be divided into two categories: external flash debugging and internal SRAM debugging (external SDRAM / hyperram debugging is not considered for now) according to the memory property of the link location of application code (read only segment).

Because external flash data cannot be written directly as on internal SRAM, additional flash download algorithm is needed to write. Therefore, there are some differences between flash debugging and SRAM debugging in c-spy.

First of all, let’s look at the process of c-spy debugging in the internal SRAM. After the c-spy debugger starts to set the appropriate JTAG speed, it starts to suspend the CPU on the target board (i.e. Cortex-M core in MCU), and then directly writes application image data to the internal SRAM of MCU on the target board through JTAG port and AHB bus. After writing, it can be operated after optional data verification and user reset / setup Control the CPU to start executing the application program in SRAM.

Let’s look at the external flash debugging process of c-spy processing. After suspending the CPU, the c-spy debugger first loads a flashloader program (i.e. flash download algorithm) into the SRAM inside the MCU. Then, the CPU is executed by the CPU to complete the flash writing of the application image data. After the burning is completed, the CPU is suspended again for optional data verification and user reset / setup, and then the CPU is manipulated Execute the application in flash.

You need to pay special attention to the optional CPU reset actions in these two flow charts. We can see that in the SRAM debugging process, there is only one CPU reset before writing the application image, while in the flash debugging process, there is a CPU reset action before and after burning the application image. Why do you need to do more CPU reset in flash debugging? This is because flashloader program will initialize MCU peripheral modules (such as clock, GPIO, flexspi, etc.), if these initialized MCU peripheral modules are not reset to the initial state, they may have some impact on the execution of subsequent applications.

3、 Full resolution of reset type

Now, let’s get to the main topic and start to introduce the reset type. The CPU reset mentioned in the previous section is only a general statement, and its specific reset behavior is compatible with IAR. Different hardware simulators have different names for reset types. This paper mainly introduces two most commonly used simulators on i.mxrt: j-link and daplink.

3.1 cortex-m7 reset function

No matter what kind of emulator, it all relies on cortex-m7 kernel function. The kernel integrates reset support in the aircr register of SCB module. Open the generic user guide manual of CM7, and you can find the following aircr register definitions:

  • Vectreset: this reset covers all corners of the CM7 processor except the debug logic. However, it will not affect any circuits outside the CM7 processor, so the on-chip peripherals and other circuits on the MCU are not affected.
  • Sysresetreq: this reset will affect the entire circuit on the chip: it will enable the CM7 processor to make the request line sent to the system reset generator valid. However, the system reset generator is not a part of CM7, but implemented by the chip manufacturer. Therefore, different chips have different response to this reset.

3.2 j-link reset type

  • Normal (reset number 0): the default reset strategy, which is equivalent to the core and peripherals mode for i.mxrt
  • Core (reset number 1): reset the core with the vectreset bit function of aircr register in Cortex-M kernel module SCB
  • Core and peripherals (reset number 8): reset the core and MCU peripheral modules simultaneously with the vectreset bit and sysresetreq bit of aircr register in Cortex-M kernel module SCB
  • Reset pin (reset pin 2): reset the MCU by pulling down the reset pin of j-link (usually connected to MCU reset pin)

The rest of the reset types are not applicable to i.mxrt and will not be introduced for the moment.

3.3 daplink reset type

  • Disabled (no reset): as the name suggests, there is no reset action
  • Software: reset the PC pointer of CPU directly to the entry function of application program, which is equivalent to soft reset
  • Hardware: reset MCU by flipping nsrst / nreset pin of daplink (usually connected to MCU reset pin)
  • Core: reset the core with the vectreset bit function of aircr register in Cortex-M kernel module SCB
  • System: reset the core and MCU peripheral modules simultaneously by vectreset bit and sysresetreq bit of aircr register in Cortex-M kernel module SCB

The remaining several types of reset have little significance in i.mxrt and will not be introduced for the moment.

4、 Influence of reset type on online debugging

The influence of reset type on online debugging can be divided into two types: one is whether it affects the normal debugging of the application program; the other is whether it affects the normal operation of the application program. As for the second point, because of the differences in the design of applications, it is impossible to determine the impact of non reset peripherals caused by different reset types on them. Therefore, we will not discuss this point for the moment, but we will focus on the first point.

Does setting different reset types affect the normal debugging of the application (can it stop at the program entry function and can it be single step)? PI Ziheng measured the LED in SDK on mimxrt1060-evk_ The blinky routine selects debug (in SRAM) and flexspi_ nor_ Debug (in flash) two builds have done a lot of tests, and the results are as follows:

Routine build simulator Reset type BootMode Debugging phenomenon
debug J-Link


DAPLink
be-all 2’b01 – SDP


2’b10 – Flash Boot
Normal download and debugging
flexspi_nor_debug J-Link – Core 2’b01 – SDP


2’b10 – Flash Boot
Normal download and debugging
flexspi_nor_debug J-Link – Normal


– Core and peripherals


– Reset Pin
2’b01 – SDP Normal download, verification failed at 0x6000000, unable to debug
flexspi_nor_debug J-Link – Reset Pin 2’b10 – Flash Boot Normal download and debugging
flexspi_nor_debug J-Link – Normal


– Core and peripherals
2’b10 – Flash Boot Download normally, check warning at 0.60 million, but debug normally
flexspi_nor_debug DAPLink – Disabled (no reset)


– Software


– Core
2’b01 – SDP


2’b10 – Flash Boot
Normal download and debugging
flexspi_nor_debug DAPLink – Hardware


– System
2’b01 – SDP Normal download, verification failed at 0x6000000, unable to debug
flexspi_nor_debug DAPLink – Hardware 2’b10 – Flash Boot Normal download and debugging
flexspi_nor_debug DAPLink – System 2’b10 – Flash Boot Download normally, check warning at 0.60 million, but debug normally

From the test results in the table above, we can draw the following conclusions:

  • Conclusion 1: in SRAM debugging, it is not affected by reset type and chip startup mode (only the content of SRAM can be affected by power failure)
  • Conclusion 2: in flash debugging, if you want to debug normally, you should not reset the peripherals on the chip (keep the initialization of flexspi and other modules by flashloader), or set the boot mode to flash boot (let the bootrom complete the initialization of flexspi and other modules). Because the initialization of clock / GPIO / flexspi must be reserved, the CPU can get the instructions in flash normally

At this point, setting different reset types during IAR online debugging may lead to inconsistent debugging phenomena under i.mxrt. This is the end of the introduction. Where is the applause~~~

Welcome to subscribe

The article will be posted to me at the same timeBlog Garden HomepageCSDN home pageZhihu HomepageWeChat official accountOn the platform.

Wechat search“Ruffian scale embedded“Or scan the QR code below, and you can read it for the first time on your mobile phone.