When i try to run following code (which is a blink OS default example ) with mbed-os >= 5.5, LED attached is not blinking, it turns on and remain. If i downgrade the version of OS to 5.4, blinks fine
#include "mbed.h"
DigitalOut led1(P2_0);
// main() runs in its own thread in the OS
int main() {
while (true) {
led1 = !led1;
wait(0.5);
}
}
Target
LPC1768
Toolchain:
online
@pilotak I've just tried our official mbed-os-example-blinky with current master and it works fine using one of the built in LEDs, can you check LED1 instead of your own external led.
I've tried mbed-os-5.4.7 and mbed-os-5.5.3 and it works for both on p26 (P2_0). There's another problem though the timings don't match, the wait(0.5) gives us totally different blink frequency.
Good 5.4.7:

Bad 5.5.3:

It seems that the same wait(0.5) takes either 500ms or 5s.
I don't know why but it didn't work, i tried it about on all available 5.5.* versions. There is obviously something going on...
I tried to reproduce the 10x slowdown in tick times and just couldn't do it until I rolled back the interface firmware to what the mbed-LPC1768 devices ship with, revision 16457. You could go to the LPC1768 Interface Firmware Page and try using the 21164 revision of the firmware instead.
I've tracked it down to changes with sleep for RTX idle. We've introduced changes to enable sleep for default (develop) profile. So from 5.5 platform actually goes to sleep (in between systicks), I don't know yet why it causes the sleep to last 5s. I'm not yet sure it's actual slowdown (eg whether .3 sleep would last 3s). I'll try to spend some time investigating today.
I wouldn't be surprised if it is related to a commit I made: https://github.com/ARMmbed/mbed-os/commit/408cff4f8d0dd77570a3aacd228269cc76b41f4b
I didn't think that the original firmware revision, 16457, even supported that disable debug semi host call.
I reverted my change and it doesn't seem to help it work with the 16457 revision of the interface firmware. It must have been there before but no one noticed until sleep during idle was enabled by default.
I can confirm it's fixed with new firmware. @pilotak can you confirm it fixes it for you?
the problem is that i don't have a true mbed LPC1768, but ublox C027 with LPC1768 so i can't exchange the firmware
but all code i compile in online compiler is for mbed 1768 not C027 as this one doesn't play well with OS5
If the ublox C027 (or any other LPC1768 board for that matter) has a JTAG debugging solution enabled on it but it isn't the mbed one then I suspect that attempting to enter sleep mode would halt the device in the debugger because of that semi host bkpt.
So if i got it right, i need to disable JTAG debugging in order to work? how am i going to do that? i have not got any previous experince with JTAG, i came from arduino enviroment. Although it would be good to learn i suppose
I would consider this as closed. I will somehow turn off JTAG debugging later. Although it would be good that other people know.
@pilotak I should mention that my JTAG comment might be a red herring and something else might be causing your issue.
You could try running this program on your device and look at the output to verify.
#include <mbed.h>
int main()
{
uint32_t dhcsr = CoreDebug->DHCSR;
printf("DHCSR = 0x%08lX\n", dhcsr);
printf("isDebuggerAttached = %s\n", (dhcsr & CoreDebug_DHCSR_C_DEBUGEN_Msk) ? "true" : "false");
return 0;
}
@adamgreen this is the output
DHCSR = 0x03010001
isDebuggerAttached = true
@pilotak That output would indicate that the mbed-os code would probably issue a semi-host bkpt instruction in an attempt to disable the debugger. That would just halt your CPU, waiting for you to attach with some debugger software.
Maybe there is a version of the firmware for your interface chip which doesn't default to enabling halt debugging on your CPU unless you have actually connected with debugger software from your host PC?
You were right, i found older FW at this page, selected CMSIS DAP Firmware 2.01 (28 Feb 2014) and it works now, thank you.
Excellent!