Questions about STM32pendSV

wowow

Questions about STM32pendSV [Copy link]

I want to try DIY RTOS on STM32 recently.
PendSV is used to complete task field switching.

The problem now is that when running by software simulation, the pendSV exception service can be executed immediately after setting the suspension.
However, it is not the case when running by hardware simulation. The pendSV exception service will not be executed until an unknown time after setting the suspension.

Environment: STM32F107VC / JLINK v8 / Keil RV 3.5 version

qiyuan775

                                 Generally, pendSV is set to a low priority. Therefore, if PendSV is set in other interrupts, PendSV will not be executed until the other interrupts are executed.

linhuanhuan

I agree with the above comments. You are right.
But my problem is that I found that the PendSV service is not running even though I have entered thread mode.
I opened the Peripherals->Core Perihperals->NVIC window.
In the Pend System Service, the E and P columns are both 1.

lcw606

                                 PendSV can only respond when interrupts are turned on. If the Thread mode neither blocks interrupts nor exceptions, it makes no sense to set PendSV to suspend but not respond. First rule out hardware problems. I think the possibility of hardware problems is not high.

zhongyanchao

Another question is how did you observe the phenomenon that "under the hardware environment, pendSV does not know when it will be executed"?
Is it because of the uncertainty introduced by your observation method?

nec

This problem occurs when I am tracing in single-step mode. After tracing many steps, PendSV does not come out to serve.
However, I set a breakpoint directly at the service entry of PendSV and was able to catch the service of PendSV when running at full speed.

sheji105

Oh, then try running the reverse IO at full speed and observe the changes in IO.
Don't use the debugger function.

gjfzb

From the breakpoint of PendSV, I checked the address in the stack, and it was indeed behind the address where PendSV was suspended. I was depressed.
I have used the method above, but in a complex system like mine, it is too difficult without a debugger.

shaolin217

By the way, you can only set PendSV in Thread mode. You can try to set PendSV to the highest priority to see if you can enter immediately.
If you still can't enter immediately, you should suspect whether the debugger has done something.

If PenSV is not easy to debug, you may think about whether there are other ways, such as using an unused peripheral interrupt to virtualize PendSV.

sabergemini

Without using an emulator, run the reverse IO at full speed and use an oscilloscope to observe the execution time relationship. This method will really become a nightmare for debugging RTOS!
In the PendSV service, I looked at the breakpoint address in the stack, but it was after the instruction that suspended pendSV. Was I fooled by JLINK?

k77777

                                 When you set a breakpoint at the entry point of PendSV, can't you reach the breakpoint when running single-step? I have also found that the running order is a little different when using JLINK single-step debugging and full-speed running. I still don't understand why. I guess it is some setting problem in JLINK options.

builds

to: Above, single-step tracing cannot enter the PendSV service program
to: 9th floor, both Thread mode and Handle mode have PendSV set to suspend. No priority is set, PendSV and others are all priority 0. There is also such a problem when using ULINK.

diannao

                                 The OP uses PendSV to switch tasks, but cannot enter PendSV when single-stepping. So can I switch tasks when single-stepping? It is not that I am always running in one task when single-stepping. What I mean is that maybe when single-stepping, the step of entering PendSV is not displayed, or try single-stepping with step into instead of step over.

wolv

To: Upstairs. I use step into to debug in the disasamble window.
The latest progress is that I changed to the previous ULINK1 debugging last night and found that I could enter the PendSV service normally. It seems that the JLINK debugger can really "debug" it!