Getting stuck with tickless mode

[Giovanni]

I think the problem is with that assertion itself, I think that if you remove it the system should run stable.

It is related to the very first problem we had, I have to decide if try to suppress those spurious interrupts (happening once in an hour or so apparently in your case) or just ignore them. I removed an SR clearing instruction in st_lld.h so this is why this is popping up again. The code is written to tolerate those extra interrupts because this is the safest approach.

Suppressing them would make the tickless code less efficient so I think I will just remove that assertion, could you confirm that removing the assertion the system runs stable?

About the timers list, strange, the new macros look correct, I will make some extra tests there.

Giovanni

[steved]

I think the problem is with that assertion itself, I think that if you remove it the system should run stable.
Giovanni

Done - nearly 11 hours without a murmur so far. I'll give it another 24 hours or so then revert to the full software if all looks OK.

[Giovanni]

Great, and thanks for all the support.

Giovanni

[steved]

Great, and thanks for all the support.

Giovanni

No problem; I appreciate your tenacity in tracking down bugs (whoever's they are).

Still running after 35 hours, so I've restored my full code to check that also runs OK.

[rbarreiros]

It seems I'm suffering from the same problem with the MCU being stuck after a few seconds in tickless mode.

I tried with all debug options on, all debug options off, the behavior is always the same, about 10~20 seconds it gets stuck.
doing a ctrl+c on gdb (I'm using cmd line gdb) when it gets stuck and a backtrace reveals always the same backtrace (regardless of debug options)

(gdb) target remote :3333
Remote debugging using :3333
0x08000278 in _idle_thread (p=0x0) at ../ChibiOS/os/rt/src/chsys.c:68
68 chRegSetThreadName("idle");
(gdb) monitor reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000140 msp: 0x20000400
(gdb) load
Loading section startup, size 0x140 lma 0x8000000
Loading section .text, size 0x133c lma 0x8000140
Start address 0x8000140, load size 5244
Transfer rate: 7 KB/sec, 2622 bytes/write.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x08000278 in _idle_thread (p=0x0) at ../ChibiOS/os/rt/src/chsys.c:68
68 chRegSetThreadName("idle");
(gdb) bt
#0 0x08000278 in _idle_thread (p=0x0) at ../ChibiOS/os/rt/src/chsys.c:68
#1 0x08000222 in _port_thread_start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit

The project used is this:
https://github.com/rbarreiros/Basic-ChibiOS

MCU is STM32F103C8T6

Anything else I can do to help further about this issue ?

[Giovanni]

Enable debug options and see if something is caught.

Also, is the stop random or it occurs after the same number of seconds?

Giovanni

[rbarreiros]

Just did a small timing test, and in the 4 tries I just did, it stops at the same time, about 33 seconds after reset. (see the link to the project in the previous post to check the timings I'm using)

[Giovanni]

Clear, it is related to the 16 bits counter you are using (systick at 2000 * 33 = ~2^16), this is why I asked. I will look into this tomorrow.

Probably some of the changes forced by MISRA rules broke something in that special case.

Giovanni

[rbarreiros]

This is what I get while debugging, after it gets stuck, I hope it helps.

debug_global.png (8.94 KiB) Viewed 6356 times

debug_threads.png (16.5 KiB) Viewed 6356 times

debug_timers.png (7.68 KiB) Viewed 6356 times

[rbarreiros]

debug_tracebuffer.png (62.91 KiB) Viewed 6356 times

debug_statistics.png (14.29 KiB) Viewed 6356 times