PwmOut on K64F does not work

[janjongboom]

mbed Classic (works):

#include "mbed.h"
PwmOut led(D3);

int main() {
    while(1) {
        for(float p = 0.0f; p < 1.0f; p += 0.1f) {
            led = p;
            wait(0.1);
        }
    }
}

mbed OS, doesnt work:

static PwmOut led(D3);
float a = 0.0f;
static void blinky(void) {
    a += 0.1f;
    if (a > 1.0f) a = 0.0f;

    led = a;
}

void app_start(int, char**) {
    get_stdio_serial().baud(115200);
    minar::Scheduler::postCallback(blinky).period(minar::milliseconds(100));
}

This is kind of a real problem for me, as a bunch of things I need to demo on Monday require PWM...

[bogdanm]

Cc @0xc0170. Any idea why this would happen?

[ciarmcom]

ARM Internal Ref: IOTSFW-2112

[0xc0170]

Quick update, that we are investigating this failure.

The online compiler is using armcc, thus I started with armcc. It works (debug, release), using application shield, d5 pwm channel and some others (d8, d9).

gcc target however works only with a debug build, the release goes to hardfault. Here's a snippet from gdb bt:

#0  HardFault_Handler ()
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/mbed-hal-k64f/source/bootstrap_gcc\startup_MK64F12.S:259
#1  <signal handler called>
#2  0x00002806 in uvisor_write32 (val=<error reading variable: Incompatible types on DWARF stack>, addr=<optimized out>)
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/uvisor-lib/uvisor-lib/secure_access.h:57
#3  FTM_HAL_SetChnCountVal (val=0, channel=<optimized out>, ftmBaseAddr=1073971200)
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/mbed-hal-ksdk-mcu/mbed-hal-ksdk-mcu/TARGET_KSDK_CODE/hal/flextimer/fsl_ftm_hal.h:491
#4  pwmout_write (obj=obj@entry=0x1fffa634 <led>, value=value@entry=0)
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/mbed-hal-ksdk-mcu/source/pwmout_api.c:87
#5  0x00002912 in pwmout_period_us (obj=obj@entry=0x1fffa634 <led>, us=us@entry=20000)
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/mbed-hal-ksdk-mcu/source/pwmout_api.c:118
#6  0x00002a04 in pwmout_period_ms (ms=20, obj=0x1fffa634 <led>)
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/mbed-hal-ksdk-mcu/source/pwmout_api.c:107
#7  pwmout_init (obj=0x1fffa634 <led>, pin=PTA2)
    at C:/Code/git_repo/github/yotta_thing/example-mbedos-blinky/yotta_modules/mbed-hal-ksdk-mcu/source/pwmout_api.c:59
#8  0x000066be in __libc_init_array ()
#9  0x00001cc6 in _start ()
#10 0x00001cc6 in _start ()
#11 0x00001cc6 in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I'll continue investigating tomorrow.

[hugovincent]

#2 0x00002806 in uvisor_write32 (val=<error reading variable: Incompatible types on DWARF stack>, addr=<optimized out>)

Is uVisor active? If so, does that mean you haven't declared the PWM peripheral in your ACLs? cc @AlessandroA

[AlessandroA]

@hugovincent uVisor is disabled by default, and I don't think it has been enabled in this case. When uVisor is disabled the uvisor_read() API is turned into a regular read through an inline asm, which might have been distorted/modified by the compiler. In that case, it would be a uVisor bug on how the read is performed in assembly.

I've received the binaries from @0xc0170 and will be debugging them tomorrow.

[0xc0170]

An update, we pinpointed that this is related to macros (from the stack trace above, this line #2 0x00002806 in uvisor_write32 (val=<error reading variable: Incompatible types on DWARF stack>, addr=<optimized out>) which were introduced to k64f header files.

@AlessandroA provided a local fix which solved this problem for the code snippet above. It should be fixed soon.

[AlessandroA]

Fixed in ARMmbed/uvisor-lib@9d0de31

A new version of uvisor-lib has been released (v1.0.13), containing the bug fix. Please update your dependencies with yotta update to get the latest version.

[0xc0170]

@janjongboom Please test, and report back . Plus close this issue if it's fixed.