Hello everyone, I’m a ruffian Heng. I’m a serious technical ruffian. What I want to share with you today isSummary of the phenomenon of using different reset strategies in online debugging under mcuxpresso IDE。
This article is actuallySetting different reset types in IAR online debugging may lead to inconsistent debugging phenomena in i.mxrtIn the same series, the plan of PI Ziheng is to write all the reset strategies under several classic ides (IAR EWARM, Keil MDK, mcuxpresso IDE), but he hasn’t found the time. Today, piziheng just helped an Indian colleague to solve the problem of using mcuxpresso online debugging on the client board. Therefore, he carefully studied the reset strategy under mcuxpresso IDE and specially shared it with you.
Before reading this article, it’s better to write a previous article by PI ZihengNotes for flash debugging using j-link download algorithm under mcuxpresso IDENow, this article is going to explore more in depth than the previous article.
- Note: the mcuxpresso ide version of PI Ziheng test is v11.3.0_ 5222。
1、 Debugging problems encountered on client board
Let’s first review the debugging problems encountered by customers. According to a colleague from India, the i.mxrt1052 board designed by the customer uses flash s25fl128lagmfi01 produced by cypress. The customer sent a sample card to my colleague. My colleague casually found the Hello world project (mcuxpresso IDE) in the SDK on the customer’s board for online debugging, and the debugger is NXP’s lpc-link2.
i. The default download algorithm selected in mxrt1050 SDK project is applicable to the default hyper flash on the official evk, but not to the QSPI flash on the board of the customer. Therefore, Indian colleagues have made a linkserver flash driver (mcux download algorithm) for the customer, which can be downloaded by using this new download algorithm (at least flash write can be seen from the download log of mcux) However, the breakpoint failed to stop in the main function, so it was impossible to debug in one step. Moreover, after checking the space of 0x6000000 in the IDE, you can see the following invalid data, just like the program was not downloaded at all. What’s the matter? Next, I will analyze the reset strategy of mcuxpresso IDE, and finally solve the puzzle for you.
For the production of linkserver flash driver, please refer to what PI Ziheng has written beforeSerial nor flash download algorithm (mcuxpresso IDE)But in fact, the s25fl128lagmfi01 selected by this customer is a common QSPI nor conforming to JEDEC SFDP standard and mimxrt1050 in the installation directory of mcuxpresso ide_ SFDP_ QSPI.cfx The algorithm can be used directly (the path is the_ 11.3.0_ 5222\ide\binaries\Flash）。
2、 Debugging mechanism and debugging classification of mcuxpresso IDE
The principle of debugging mechanism in mcuxpresso IDE_ 11.3.0_ 5222\MCUXpresso_ IDE_ User_ Guide.pdf There is no design introduction in the manual. Although there are four chapters about download debugging in the manual, it mainly introduces how to use download debugging function in IDE.
10. Debug Solutions Overview 11. Debugging a Project 14. The GUI Flash Tool 15. LinkServer Flash Support
However, the debugging mechanism is similar in all ides, and the design concept is consistent. This part is recommended for referenceSetting different reset types in IAR online debugging may lead to inconsistent debugging phenomena in i.mxrtThe first and second chapters in.
3、 Full analysis of reset type
OK, now let’s get to the point and start to introduce the reset type under mcuxpresso ide. We know that different hardware simulators have different reset functions. Piziheng mainly introduces two most commonly used simulators on i.mxrt: j-link and daplink. In addition, no matter what kind of emulator it is, it has the help of cortex-m7 kernel function. The kernel integrates reset support in the air register of SCB module. SeeSetting different reset types in IAR online debugging may lead to inconsistent debugging phenomena in i.mxrtOf3.1 cortex-m7 reset functionSection.
3.1 j-link reset type
There are three settings of j-link reset type in mcuxpresso IDE, as shown in the figure below. In essence, they are all set with the help of JLINK underlying command. For details, you can set the j-link reset type in the_ V686f\Doc\Manuals\UM08001_ JLink.pdf In the documentSupported remote (monitor) commandsThe reset command in section andList of available commandsDetailed explanation can be found in the setresettype command in the section.
UM08001_ JLink.pdf In the document7.10.2 Strategies for Cortex-M devicesThe following three reset types are listed in this section:
- 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 help of vectreset bit function of air register in SCB of Cortex-M kernel module
- Reset pin: reset the MCU by pulling down the reset pin of j-link (usually connected to the MCU reset pin)
Although the three settings in the reset type setting box in the figure above can enable reset operation, the stages are different. The settings in red box 2 are pre download operation, the settings in red box 3 are post download operation, and the settings in red box 1 are pre execute operation. If you don’t know about this sequence, you can do an experiment. For example, we set reset type 1 in red box 3 and reset type 2 in red box 1. After debugging, we find the jlinkserver log in the log window and view the specific sequence in the log.
In practical use, piziheng recommends not to enable the “reset before running” option in red box 1, and only set the reset type in red box 3. After testing, this method is most consistent with the debugging experience in other ides. However, there are two points to note:
- Note1: after the reset command, you must add a monitor reg PC setting, otherwise you cannot debug normally.
- Note2: when the reset type is 0, if the bootrom fails to start the app normally (that is, it should not be debugged normally), but sometimes it stops at the main function in the IDE interface. This is an illusion (it should be related to the cache) and cannot be debugged normally. Click the suspend button to see the run.
3.2 linkserver reset type
Linkserver, which corresponds to daplink debugger, is the default debugger type of mcuxpresso ide. Ide implements friendly reset type options for this default debugger.
The “reset handling” in the red box 1 of the reset type setting in the figure above provides a total of five reset options. Except for soft, the rest of the five resets will not set PC pointer actively. By default, breakpoint will trigger debugging.
- Default: equivalent to sysresetreq mode
- Sysresetreq: use the sysresetreq bit of air register in SCB of Cortex-M kernel module to reset MCU peripheral module at the same time
- Vectreset: reset the core with the help of vectreset bit function of air register in SCB of Cortex-M kernel module
- Soft: directly reset the PC pointer of CPU to the entry function of application program, which is equivalent to soft reset
- Null: equivalent to sysresetreq mode
Just like the JLINK reset type in the previous section, the linkserver also provides additional commands settings (red box 2 / 3). Please refer to mcuxpresso for specific command writing_ IDE_ User_ Guide.pdf The manual is not detailed in this paper.
As for the result of Reset handling’s choice of SOFT mode, we need to point out that we can see in the following corresponding log that soft reset is called after the download is completed and SP and PC are taken from 0x60000000, that is MCUXpresso. IDE thinks that the first download address is the starting address of the program interrupt vector table. This assumption does not hold in the XIP project of i.mxrt. We know that the correct starting address of the interrupt vector table should be 0x60002000. If you want mcuxpresso ide to get the correct SP / PC, you should use XIP in the pre compile option of XIP project_ BOOT_ HEADER_ Set enable to 0 (you can also add the linkserver command in red box 3 to set PC), otherwise you can’t debug normally.
4、 Influence of reset type on online debugging
The impact of reset type on online debugging can be divided into two types: first, whether it affects the normal debugging of the application; second, whether it affects the normal operation of the application. For the second point, due to the differences in the design of applications, it is impossible to determine the impact of non reset modules caused by different reset types on it. Therefore, we will not discuss this point for the moment, and we will focus on the first point.
Does setting different reset types affect the normal debugging of the application (whether it can stop at the program entry function, whether it can carry out single step)? Piziheng measured led in SDK on mimxrt1050-evkb_ Blinky routine, select flexspi_ nor_ Debug (in flash) build has done a lot of tests, and the results are as follows:
|Routine build||simulator||Reset type||BootMode||Debugging phenomenon|
|flexspi_nor_debug||J-Link||monitor reset 1||2’b01 – SDP
2’b10 – Flash Boot
|Normal download and debugging|
|flexspi_nor_debug||J-Link||monitor reset 0/2||2’b01 – SDP||Normal download, unable to debug|
|flexspi_nor_debug||J-Link||monitor reset 0/2||2’b10 – Flash Boot||Normal download and debugging|
|flexspi_nor_debug||LinkServer||– SOFT||2’b01 – SDP
2’b10 – Flash Boot
|Normal download and debugging, note that the program can not contain XIP header|
|flexspi_nor_debug||LinkServer||-Except soft, the other four||2’b01 – SDP||Normal download, unable to debug|
|flexspi_nor_debug||LinkServer||-Except soft, the other four||2’b10 – Flash Boot||Normal download and debugging|
From the test results in the table above, we can draw the following conclusions:
- Conclusion 1: in flash debugging, if you want to debug normally, either do not reset the peripherals on chip (keep the initialization of flexspi and other modules by flashloader), or set the startup mode to flash boot (let bootrom complete the initialization of flexspi and other modules), because the initialization of clock / GPIO / flexspi must be reserved, so that the CPU can get the instructions in flash normally.
- Conclusion 2: under JLINK reset, the debugging experience of mcuxpresso IDE is consistent with other ides.
- Conclusion 3: the vectreset reset mode in mcuxpresso ide can’t achieve the same effect in other ides, because the initial PC can’t be obtained.
5、 Causes of debugging problems on client board
Finally, back to the problem on the customer board, the Indian colleagues of piziheng are actually very experienced. The board startup mode setting, flash download algorithm, and fdcb header in the project are all correct. However, it is found that the boot in eFuse of board i.mxrt1052 chip is correct_ CFG2  bit is burned to 1, that is, the chip enters the inifnite loop mode, the PC stops in the bootrom forever, and the client app will not be started, so it cannot be hard reset before debugging.
Boot in bootrom system initialization function_ CFG2  bit processing code:
volatile uint32_ t infinite_ loop;
So far, the phenomenon of using different reset strategies in online debugging under mcuxpresso ide has been summarized. Where is the applause~~~
Welcome to subscribe
Wechat search“Ruffian scale embedded“Or scan the following QR code, you can see it on your mobile phone for the first time.