Search Results

I am in the process of doing a proof-of-concept migration of some old code that uses embOS 3.80h with IAR EWARM 5.2 to embOS 5.10 with IAR EWARM 8.5. I am a little stuck on how to properly initialize the multi-threading support. With the old software our code simply called OS_INIT_SYS_LOCKS(). That doesn't seem to do the trick with the new software - I get the following linker errors: > Error[Li005]: no definition for "__iar_system_Mtxinit" [referenced from xsyslock_mtx.o(th7M_tln.a)] > Error[Li…

Nino: The board I am working on is our own board where a STM32F103 chip was removed and a STM32F205 soldered in place. I am working on getting an STM3220G-EVAL board which uses the similar STM32F207 chip. Until then, the IAR EWARM v5.20 debugger does work with J-Link JTAG on the modified board I have. If there is some log from that or other diagnostic that might give you information, please let me know. Thanks, -- Michael Burr

Thanks for the response, Fabian. I did the following: - used the JLinkDLLUpdater.exe to update the DLL in IAR (to v6.82g) - changed the IAR project settings to Cortex M3 device - changed the IAR project settings to uncheck the "use Flash downloader" box in the Debugger config dialog But the J-Link DLL never showed the Device Selection dialog when I rebuilt the project and told it to "Download and Debug". The small "Downloading Application" dialog displays a progress bar (only one progress bar - …

I'm evaluating Ozone 3.20e with an STM32F205ZG chip and a v9.1 J-Link. I flashed the device earlier using JFlash, and am trying to start the debugger using the "Attach & Halt" command. I get the following error dialog: =================== The target stopped in HardFault exception state. Reason: A fault with configurable priority has been escalated to a HardFault exception at 0x00000000. For more information about analyzing faults on Cortex-M, refer to: wiki.segger.com/Cortex-M_Fault. ===========…

We are currently using IAR EWARM 5.2 to support an old device that has an STM32F103xx device using J-Link Plus to flash the device and debug. That all works great. We are looking into updating the device and possibly moving to an STM32F205xx device which IAR EWARM 5.2 doesn't support. In order to do some initial checkout, I'd like to use that combination of tools -IAR 5.2 and J-Link Plus - but I can't figure out how to get the STMF205 flashed. JFlash supports the STM32F205, so I'm wondering if t…

I'd like to have a quality check process that runs a test of external RAM on a STM32 micro without modifying the firmware that is currently flashed on the device. So I'm wondering if it's possible for the Flasher ARM to have a program image that is linked to reside on the STM32 internal RAM, download that program image to the STM32, and start that RAM resident program running without modifying whatever is currently in the STM32's flash?

I have started looking at the Ozone debugger, and I am using Ozone with an existing project built with IAR Workbench 5.20. First of all, I was pleasantly surprised that Ozone understood the IAR generated symbols (then again - I don't know if IAR's symbol format is based on GDB's or what). But when I tried to use the embosPlugin.dll, the "Threads" window doesn't show any of the tasks. This feature does work fine in IAR 5.20 with the IAR embosPlugin.dll I have installed there. I am wondering if th…

Thanks for looking into this. Would it work just as well to uncheck the "Debugger | Download | "Use flash loader(s)" option in the IAR project? Or do we need to do *both* things (uncheck the IAR project option *and* perform the JLink configuration you described?). I have sometimes wondered about the "Use flash loader(s)" option in the IAR project - I seem to recall that it was turned on way back when because of problems we ran into when it wasn't checked. But that could be my memory playing tric…

OK, I've sent an email with a link to an IAR project that should reproduce the problem. In preparing the project I've found more information: While preparing this repro case, I've determined the settings that seem to trigger the problem. The reproduce the problem, you must: - use a relatively new JLinkARM.dll (I have reproduced the problem with versions 4.54c through 4.56a) - have at least one breakpoint set. - have the following IAR project setting enabled/checked: Source Code (1 line) I notice…

Alex: I can't dig up an eval board here that has enough flash to hold the image (I've got a STM32-SK, but it only has 128KB of flash). I can pretty easily configure the project for a 256KB board and send you the *.out and *.sim files files generated by IAR, I can also send the image as an Intel hex formatted file. I won't be able to send the whole project, but all that needs to happen is for the image to be flashed - you don't need to build the project. The page that has been left erased is alwa…

When using JlinkARM.dll versions between 4.54c and 4.56a (inclusive) to flash my device for debugging, the image ends up with one 2KB page of flash remaining erased in the middle of the image. When I look at the information in the binary produced by IAR (including an Intel HEX format file of the image), it looks like the correct data is produced by the compiler & linker for that page. The page is incorrectly flashed/left erased and no problem is indicated after the verification pass of the flash…

Thanks for making this clear.

Some of the examples in the embOS_Generic.pdf manual call OS_IncDI() before doing anything else in main(). But some do not. In none of these example snippets is there a all to either OS_DecRI() or OS_EI() - I assume this happens in one of the subsequent initialization functions (OS_InitKern(), OS_InitHW(), or OS_Start()) and that it's performed unconditionally - not by decrementing the counter and enabling if it reaches 0. Could I get clarification on whether or not a call to OS_IncDI() is neces…

I would also like to know if there are plans for Cortex-A8 support in the gdb server.

Quote from Arne: “The '&' in front of '_acMemQBuffer' (line 5) puzzles me: that would be a pointer to a pointer to a memory area. Or am I wrong?” An array name often (nearly always) evaluates (or 'decays') to a pointer to the first element of the array, but the array is not itself a pointer. Taking the address of the array (&_acMemQBuffer) also results in a pointer to the array (the pointer is of a different type, though), not a pointer to a pointer. Both expressions will be pointers with the sa…

Quote from swe: “ I used the OS_LeaveInterruptNoSwitch() at the end of the ISR.” From your description, it sounds like you should use OS_LeaveInterrupt() so that your task that's waiting on this event will be scheduled immediately (if there's no higher priority ready task). I believe that the use-case for OS_LeaveInterruptNoSwitch() is pretty rare.

I mistakenly passed 0 as the TimeSlice parameter for OS_CreateTaskEx() calls when I was performing a wide-ranging refactoring; things continued to work at first glance, but with continued use things didn't behave well, but in a subtle, non-obvious way. I assume that 0 is invalid for a TimeSlice parameter, since the OS_SetTimeSlice() API docs mention: 1 <= TimeSlice <= 255 Note that this detail isn't called out in the OS_CreateTask()/OS_CreateTaskEx() API docs - it probably should be. However, th…

You might want to post the Debug Log that IAR generates - I don't have a selection for "Reset Pin" in my J-Link configuration (but I'm using a somewhat older version of IAR and a different STM32 device) - so we can know exactly which reset strategy the JLinkARM.dll is using. Mine is using "Type 0: Normal" which seems to use the reset pin only as a near last resort. My IAR configuration dialog only shows me "Normal", "Core only", and "Core and Peripherals" strategies. Take a look at the J-Link/J-…

I'd like to request that this message box notification be configurable (or removed). I stil haven't gotten used to it (I'm running v4.12 now), and I still find it annoying.

Thanks very much for this infomratino - I think it'll be a big help in debugging this. Unfortuantely, all I have at this point is a log message that says the OS_Error() was called with that particular error code and which task was active at that time. I have no core dump or stack trace, so I don't know what function might have called OS_Error() or what the stack usage was at the time. I can monitor stack use in a repro attempt, but hopefully knowing what part of the TCB is likely to be corrupted…