Search Results

I've got a problem in my code where embOS is calling OS_Error() indicating that the problem is OS_ERR_INV_TASK. I'm wondering what data item embOS is determining is corrupt that causes it to throw that error so I can narrow down my troubleshooting to the right areas (unfortunately I'm working without a source license to embOS). Note that I want to make clear that I understand this isn't an embOS problem - some data structure is being corrupted (probably a TCB). I'm just wondering if there's a pa…

As a potential temporary workaround did you try reverting the JLink DLL and just leaving the firmware on the JLink device at the newer version?

Is it possible that the missed event occurs when the task isn't actually waiting yet? If nothing is actually waiting on the event when OS_EVENT_Pulse() gets called, the event will never be 'seen'. If the task is the only thing that will ever wait for the event, it might be better to simply use OS_EVENT_Set() rather than OS_EVENT_pulse() so the task waiting for the event will see it regardless if the event is set while it's waiting or not. Or use a OS_CSEMA counting semaphore if the task needs to…

The embos_cm3_iar.pdf file has the documentation for this (if you're using something other than IAR tools I assume that there's a similarly named document that has the details for your particular platform). There are 2 key items: 1) embOS (at least in a default build) does not disable interrupts with a priority higher than 128 (ie., interrupt levels 0-127 are never disabled). Those so-called "fast interrupts" cannot make any embOS API calls. So make sure your interrupt that you want to call OS_S…

Thanks- I'm starting to see a common theme... every answer to my questions is "that's already addressed in the newer versions". I'll have to get the priority of the move to 3.80h bumped up.

In prior versions of embOS that I used with IAR Workbench and ARM7/9 CPUs there was documentation for configuring IAR's DLIB to be thread safe by somehow configuring it to use embOS mutexes for certain operations. This involved wither rebuilding DLIB with some special headers and/or calling OS_INIT_SYS_LOCKS() at some point in the system initialization. I'm currently working with an embOS built for the Cortex M3 (embOS 3.60d, soon to be 3.80h I think). However, there's no mention of this in docu…

I already hook into OS_Error() for helping with detecting bugs during development. We're currently using embOS 3.60d which I know is pretty old. The project will soon update to 3.80h which we have already downloaded (I think this is a pretty recent version). I'm not sure if we're still on support - I'll follow up on that from this end. Thanks for the information on all this.

Fantastic - thanks for the updated docs. This will be a big help. It's great when a vendor is a couple steps ahead of me. Now, by any chance does the debug version of the OS attempt to check if an API is being used in an invalid context and drop into OS_Error() if so? I think this would help me ferret out some bugs in the code base I'm working on, so if that's not there consider this post an enhancement request.

I didn't find a clear delineation between what embOS APIs are safe to call in a timer callback and which are not. From the embOS_Generic.pdf, i see the following: Quote: “Timer routines are similar to interrupt routines; they have a priority higher than the priority of all tasks. For that reason they should be kept short just like interrupt routines. ” Are there APIs that are unsafe to call since we're not in a task context? Clearly it doesn't make sense to call something that might potentially …

I'm a little confused about this announcement as well. Our project is currently using IAR Workbench with an STM32 microcontroller. IAR has been able to program the flash on this since day 1 (at least since I've been on the project). As far as I know, no special license from Segger was necessary for this to work. When we heard about this announcement we were hoping that this would enable us to have our QA folks flash parts for testing without having to go through someone with an IAR installation …

So this message is triggered by something harmless that IAR is doing that it no longer does in 5.40a? Is there a way to configure or otherwise prevent the JLink driver from displaying the message (it didn't before I installed 4.08l)? It's unlikely that I'll be able to upgrade IAR since that'll require the whole team to upgrade (IAR's project files don't work well in varying versions of the IDE). Like I said before, it's not a big deal, but it is a mild annoyance and it's new (I'd probably never …

I've recently updated to the J-Link ARM V4.08l software package (from 4.08h, I think), and I'm now getting the following messagebox whenever I start a debug session: --------------------------- J-Link ARM V4.08l Warning --------------------------- Debugger writes to flash (2 bytes @ address 0x0805F450) after flash download is completed. Write to flash is performed. Further writes to flash memory will not cause a similar message box. --------------------------- OK --------------------------- I'm …