ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderator: RoccoMarco

Vooon
Posts: 15
Joined: Tue Feb 01, 2011 11:13 pm

ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Vooon »

Hi all,

I want to use polled ICU, but when i try to use it immediatly halts (even without indication done in SYSTEM_HALT_HOOK).
By commenting-out i found that it breaks if i call icuWaitCompletion() or I-class in lock.
Also i tried do explicit icuDisableNotifications(), and fill callbacks with empty handler, no luck.

Config:

Code: Select all

static const ICUConfig tim2_cfg = {
.mode = ICU_INPUT_ACTIVE_LOW,
.frequency = 1000000,   // 1 MHz
.width_cb = NULL,
.period_cb = NULL,
.overflow_cb = NULL,
.channel = ICU_CHANNEL_1,
.dier = 0
};


Thread https://github.com/vooon/miniecu/blob/m ... rpm.c#L119

Code: Select all

    icuStart(&ICUD2, &tim2_cfg);
    ICUD2.tim->ARR = 2000000;   // 2 sec overflow
    icuStartCapture(&ICUD2);

    while (true) {
        icuWaitCapture(&ICUD2); // BANG!
    }
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Giovanni »

What error message are you getting? I assume it ends up in the chSysHalt(), there should be a message pointed by ch.dbg_panic_msg.

Giovanni
Vooon
Posts: 15
Joined: Tue Feb 01, 2011 11:13 pm

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Vooon »

I have not used jtag debugging in this project, enough debug messages for me.
Here is the result:

Code: Select all

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/vovan/src/UAV/miniecu/build/miniecu_v2/miniecu_v2.elf
^C0x080050e0 in icu_lld_wait_edge.isra.0.10257 () at ../../ext/chibios/os/hal/ports/STM32/LLD/TIMv1/icu_lld.c:114
114       while ((icup->tim->SR & STM32_TIM_SR_CC1IF) == 0)
(gdb) p ch
$1 = {rlist = {r_queue = {p_next = 0x20001078 <wa_log.14858.5157>, p_prev = 0x20001c68 <_idle_thread_wa.4392.5246>}, r_prio = 0, r_ctx = {
      r13 = 0x0}, r_newer = 0x200016a0 <mainthread.6362.4393.5110>, r_older = 0x20001950 <wa_rpm.15834.5156>,
    r_current = 0x20001950 <wa_rpm.15834.5156>}, vtlist = {vt_next = 0x20001f40 <ch+28>, vt_prev = 0x20001f40 <ch+28>, vt_delta = 4294967295,
    vt_lasttime = 10045}, measurement_offset = 24}
(gdb) p ch.dbg_panic_msg
There is no member named dbg_panic_msg.


So as i can see icu thread consume all time and because led thread has lowest priority i assume it as hault (communication threads also don't have time).
Perhaps previous variant whith callbacks is better for this application.
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Giovanni »

The function icuWaitCapture() is meant to operate in polled mode, it waits for a capture to be available. If there is no signal in input the function stays in the loop indefinitely, probably this is the problem you are seeing.

I will look into adding a timeout capability on timer overflow.

Giovanni
Vooon
Posts: 15
Joined: Tue Feb 01, 2011 11:13 pm

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Vooon »

I rewrote back to the callbacks, but there was another problem: icuGetPeriodX() returns only 0 or 1: 0 before the first event and 1 after.
Interrupts occur (updated last_update), but the value is not correct.

https://github.com/vooon/miniecu/blob/m ... _rpm.c#L82
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Giovanni »

Hi,

You are clocking the ICU at 1MHz, what kind of frequencies are you trying to measure? is it possible the pulse is too fast?

Giovanni
Vooon
Posts: 15
Joined: Tue Feb 01, 2011 11:13 pm

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Vooon »

Normal range is 1 Hz .. 1 kHz, but usually less than 300 Hz. Test signal ~10 Hz. Also hw has small RC-filter to eliminate noise.
A similar code worked with chibios 2.6, with same signal generator from blinking arduino :).
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Giovanni »

Uhm, looks really like a bug, tomorrow I will give the ICU driver a try again, today I made some more changes to it (that timeout thing to the wait function).

I also see you set manually the "overflow" limit, not a bad idea actually.

Giovanni
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Giovanni »

This is the new behavior of the driver, overflows change the driver state back to waiting:

icu.png
icu.png (36.6 KiB) Viewed 4643 times


Giovanni
Vooon
Posts: 15
Joined: Tue Feb 01, 2011 11:13 pm

Re: ICU halt after icuWaitCapture on STM32F373 @ 3.0-git

Post by Vooon »

Giovanny,

Found one bug in icu.h 183:

Code: Select all

#define _icu_isr_invoke_width_cb(icup) do {                                 \
  if (((icup)->state == ICU_ACTIVE) &&                                      \
      ((icup)->config->period_cb != NULL))                                  \
    (icup)->config->width_cb(icup);                                         \
} while (0)


Checked wrong callback.

I added empty_handler for width_cb, but i still get 0 or 1.
Also i tryed icuGetWidthX() in period cb and get same 0 or 1.
Post Reply