[En-Nut-Discussion] Cycle counter based NutMicroDelay Implementation problems

[Uwe Bonnes]

>>>>> "Uwe" == Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de> writes:

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
    Ole> Hi all, The Cortex implementation used the System Core Debug unit
    Ole> CPU Cycle counter to implement a high precise NutMicroDelay()
    Ole> function.

    Ole> Unfortunately on the LPC CPUs it seems that the Core Debug
    Ole> registers may not be user programmed which caused NutMicroDelay to
    Ole> freeze the system.

    Ole> Curiously it works if a JTAG Debugger is connected.

    Ole> As long as this function does not work reliable it is disabled by
    Ole> default and the old NutMicroDelay implemetation is used.

    Ole> Use the new config option "NUT_MICRODELAY_CM3_CYCCNT" in the
    RTOS-> TimerManagem section to re-enable it.

    Uwe> Is this really a thing for the configurator or shouldn't the #if
    Uwe> defined(__CORTEX__) && defined(NUT_MICRODELAY_CM3_CYCCNT) line be a
    Uwe> whitelist like #if defined(MCU_STM32)

    Uwe> Otherwise we pile up tons of configuration options...

Ole,

I have implemented a SysTick based NutMicroDelay() function. Could you try
if it works for your LPC. Bitbang OWI now works on STM32F1 (72 MHz) on -O0
and -Os compiled code without any need for fiddling with with the delay-loop
value.

Should we remove the code for the DWT based approach?

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------