Search Results

This assert does not occur if we never go into Idle. It also doesn't not occur if we disable Tickless Idle. That being said I think this assert only runs when FreeRTOS come out of Tickless Idle so of course that should work. The assert does not occur if we have no breakpoints set. One of our team has found that setting a breakpoint takes 150ms (was discovered by watching our system power change - or rather stop changing). I am wondering if this happens while we are in Tickless Idle if that is en…

After enabling Tickless Idle on a NXP Kinetis M0, we are now seeing asserts from FreeRTOS when we set a breakpoint (it doesn't even have to hit it).If we don't set any breakpoints, it doesn't assert. The assert is in FreeRTOS Task.c: Source Code (1 line)It appears as if xTickCount is still moving during idle. Is there something with setting a breakpoint that changes the sleep/power save functionality related to timers? Example: Source Code (8 lines)Currently we are working around this for when w…

Yes I was referring to the Jlink Debugger. And no, connecting to the target via the J-Link Commander fails after it is in this state. And to elaborate, after a reboot, a single connection from J-Link Commander works but the next attempt will fail.

Ever since the release of El Capitan, I am only able to use the standalone debugger once. After a stop and file reload, the connection will fail until the Mac is restarted. Is anyone else having this issue? I saw issues with El Capitan and the OpenSDA firmware but this is with a Jlink Ultra connected to a STM32 Cortex M3 using the standalone Segger debugger for OS X (version 1.78 and 5.02f drivers).

This is the second year in a row our company has not got notification of when our support expires. Normally I wouldn't complain about it but it means the updates stop coming. This year I tried to preemptively fix it by emailing the info@segger.com address but have gotten no response. Is there a better contact? Do other people have this issue? Is Segger in trouble or something?

Thanks. As soon as we looked at our ICF files we saw a problem. We had changed processors and we have custom memory ranges so we can have both application and bootloader. We updated the ROM when switching to the smaller processor but missed the RAM. Stupid. Thanks.

We have been successfully running embOS on multiple STM32F103 processors but recently have some pains on a single processor when upgrading to the newest versions (3.88c). The processor in question is a STM32F103RBH7 which is set in IAR 6.60.2.5507 as the family STM32F103xB and memory model STM32F10X_MD. We are using the embOS CMSIS setup files with the IAR "Use CMSIS" option. The only modification is changing the include for device.h to stm32f10x.h. This setup was working wonderfully on our boar…

Well I have active support but I haven't heard. How long is the lag typically? Thinking I should have waited till I had the new embOS to install the new IAR.

The newest version of IAR introduced multiple compile time errors. Is there an update in the works or a work around? Or is this a problem with my installation? Error[Pe147]: declaration is incompatible with "__interwork __softfp unsigned long __get_PSP(void)" (declared at line 52 of "C:\Program Files\IAR Systems\Embedded Workbench 6.0\arm\inc\c\intrinsics.h") C:\Projects\GSCBA\Software\Sandboxes\GSCBA\LIB\source\STM32F10x_StdPeriph_Lib\Libraries\CMSIS\CM3\CoreSupport\core_cm3.h 1102

How are we informed of updates to embOS? What are the best ways to handle the multitude of interlocking tools required (CMSIS, STM32 Libs, and IAR)?

Which do most people buy? If we purchase just the Library is there a penalty (money or project changes) if we have problems and need to upgrade to the Source?